Placing a block containing a form in navigation layout prevents layout builder from saving

Problem/Motivation

Since #3443833: Provide a way for other modules to flag block plugin implementations as 'navigation safe' introduced a way to add additional types of blocks to be placed in Navigation via Layout Builder, it is now possible to add blocks that contain <form> tags when rendered. This means that after these blocks have been placed and saved, the layout cannot be saved again, because the layout form contains nested <form> tags. This identical problem affected default and override entity layouts in Layout Builder and was fixed in #3045171: Form blocks rendered inside layout builder break save. However, the fix was strictly limited to the entity view display form and the individual entity layout form.

Steps to reproduce

1. Install Drupal with standard profile
2. Install navigation module
3. Create a block that has a form in it, such as a search block or views block with an exposed form
4. Implement hook_block_alter() in some module and set 'allow_in_navigation' for the block's definition to TRUE.
5. Log in as administrator
6. Go to /admin/config/user-interface/navigation-block
7. Click on the +Add block link
8. Click the link with the text matching the block's label
9. Press the Add block button
10. Press Save and confirm you see a successful "Saved navigation blocks" message
11. (Optional) Go through similar steps to add any other block, but it's the same without doing it
12. Press Save
13. Observe that the warning message "You have unsaved changes." appears no matter how many times you press Save

Proposed resolution

The solution in [##3045171] use a form API #process callback added to the layout_builder element in DefaultsEntityForm and LayoutBuilderWidget, combined with a controller service decorator LayoutBuilderHtmlEntityFormController to move the layout builder element outside the form render array. This works because the layout builder element does not itself set values in form state, but instead interacts with the temp store to save layout data on form submit. However, the #process callback and controller apply only to the the entity form routes for the default entity display and entity layout. The navigation layout form is not a layout form, nor does Drupal\navigation\Form\LayoutForm add the #process callback to the layout builder element.

This is probably best solved by:

1. Moving the #process callback layoutBuilderElementGetKeys() from the widget and the default display forms to the LayoutBuilder render element
2. Instead of decorating the entity form controller service, in the LayoutBuilder #process callback, add #pre_render and #post_render callbacks to the containing form render array. In the #pre_render callback, render the layout builder element separate from the form, make sure to collect the cacheable metadata, and save the rendered markup as a non-renderable property. Then the in the #post_render callback, append the layout builder markup to the rendered from markup.

Remaining tasks

Postponed on reproducing a failing test in CI. Investigation: #3494332: Functional Javascript tests are silently skipped on Gitlab CI due to selenium standalone configuration

Test only build fails as expected now.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet