Auto-create/update Component config entities for all discovered SDCs that meet XB's minimum criteria

Asked @lauriii to confirm he agrees with the proposed resolution, especially with an eye towards #3464042: Add ComponentAuditabilityTest.

Today, if components or templates are being changed, the changes are reflected immediately to the site.

This is not true:

1. To have template changes reflect immediately (including SDC template changes), you'd need to enable Twig development mode at /admin/config/development/settings
2. To have component changes (aka component metadata changes) reflect … there's no way to do that, not even https://www.drupal.org/project/cl_devel does that. The only way to achieve that is to manually clear the discovery cache bin's component_plugins cache item! And since there's no cache tags associated with that, the only way to achieve that is to go to /admin/config/development/performance and click Clear all caches (more efficiently through the CLI: drush cc discovery).
   Actually … the way it's cached is so aggressive that a major core bug for it was just fixed yesterday: #3460598: Single directory component CSS asset library not picked up in admin theme immediately after module install without cache clear. 😅

IOW: to actually achieve what you describe, we'd need an SDC development mode, which re-discovers all SDC metadata on every request. We could and should do that! Opened issue for that: #3464388: SDC *.component.yml metadata is cached aggressively, gets in the way of component development.

And … when that mode is on … we'd also just automatically update the Component config entity! 🤓

Result:

1. the exact DX you describe in #8
2. the auditability described in #3464042: Add ComponentAuditabilityTest

This blocks #3464042, and at #3464042-4: Add ComponentAuditabilityTest you can find a detailed write-up that justifies both this issue as well as that one, based on XB's product requirements.

#3461499: Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings is in.

@f.mazeikis, see #3461499-24: Support complex SDC prop shapes: introduce (Storable)PropShape to compute field type storage settings for some additional context, but here's the most relevant bit:

In the MR, there's 4 @todos pointing to #3463999: Auto-create/update Component config entities for all discovered SDCs that meet XB's minimum criteria, which is where the automatic fallback logic that this added can be removed. "Automatic fallback logic" is a nice alternative phrasing for "magic 🧙", and we should avoid it. Removing that magic is an order of magnitude simpler once these component config entities are fully auto-generated. So, deferring that part to that issue 👍

AFAICT this issue would likely have independently surfaced #3465981: Follow-up for #3461499: transform at-rest field storage settings using FieldItemInterface::settingsFromConfigData(), especially if #3446722: Introduce an example set of representative SDC components; transition from "component list" to "component tree" lands before this.

#3465981 is only a soft blocker to this though, because there's plenty of other pieces to be done in this issue.

#3467162: Follow-up for #3461422: display SDC prop's human-readable name (`title`), not its machine name surfaced one additional requirement.

Discussed in detail with @f.mazeikis. He discovered oversights in (Candidate)StorablePropShape + the config schema while working on this MR. The solution is evident: a fieldInstanceSettings sibling to fieldStorageSettings. He'll extract that as a blocking issue, with a fairly trivial MR that can land very quickly, to unblock this issue to do things "properly". 👍

That's in now! 🚀

#20:

@lauriii has stated it's a hard requirement that it is possible to do it fully automatically.

As a next step, we would only do it fully automatically when in "development mode" (because on production you wouldn't want new SDCs appearing in XB. See #3464042: Add ComponentAuditabilityTest, and the discussions with @catch on that subject over at #3444424: [META] Configuration management: define needed config entity types.

Reviewed 🏓

The failing Cypress E2E tests are showing this in the output:

{
                      "status": "PARSING_ERROR",
                      "originalStatus": 500,
                      "data": "The website encountered an unexpected error. Try again later.<br><br><em class=\"placeholder\">Twig\\Error\\RuntimeError</em>: An exception has been thrown during the rendering of a template (&quot;[activation] String value found, but an array or an object is required&quot;). in <em class=\"placeholder\">Twig\\Template-&gt;yield()</em> (line <em class=\"placeholder\">1</em> of <em class=\"placeholder\">modules/custom/experience_builder/components/containers/shoe_tab_group/shoe_tab_group.twig</em>). <pre class=\"backtrace\">Drupal\\Core\\Template\\ComponentsTwigExtension-&gt;doValidateProps(Array, &#039;experience_builder:shoe_tab_group&#039;) (Line: 109)\nDrupal\\Core\\Template\\ComponentsTwigExtension-&gt;validateProps(Arr ...

… and sure enough, components/containers/shoe_tab_group/shoe_tab_group.component.yml does look rather bizarre:

    activation:
      type: array
      title: Activation
      description: When set to auto, navigating tabs with the arrow keys will instantly show the corresponding tab panel. When set to manual, the tab will receive focus but will not show until the user presses space bar or enter.
      default: auto
      examples: ['auto', 'manual']

I went back to #3446722: Introduce an example set of representative SDC components; transition from "component list" to "component tree" and found that @ctrlADel's original implementation of that (commit: ef34f8106dfe2103df38055154efc9bef9ba9b1d) was never changed by @tedbow nor me. So I think this was just an honest mistake.

Fixed in https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...

A bunch of the components that @ctrlADel added in #3446722: Introduce an example set of representative SDC components; transition from "component list" to "component tree" do have examples but then specify no examples. That's odd/weird, but XB should graciously handle that: https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...

I pushed a handful of tiny commits to help get this MR to green — because the failures were happening in areas far removed from the changes that are actually in the scope of this MR (and far outside areas @f.mazeikis has previously touched).

I also solved one very tricky thing WRT default config: https://git.drupalcode.org/project/experience_builder/-/merge_requests/1....

This MR still needs:

1. test coverage (see https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...)
2. to address remaining review feedback
3. conflict resolution

… but those should be smooth sailing now 😊🤞 Looking forward to seeing this one land! 😄

#3467972: Unable to save node article form — remove obsolete TwoTerribleTextAreasWidget + fix duplicate `XB:image` SDC unblocked this issue — thanks @f.mazeikis for reviewing that!

Tests look great!

I bet fixing https://git.drupalcode.org/project/experience_builder/-/merge_requests/1... will also fix the failing Cypress E2E test.

This feels very close now 😊🥳

This issue represents a huge leap forward! 🚀

Most importantly in the short term: this will make it an order of magnitude easier to start testing https://www.drupal.org/project/demo_design_system 👍

Also:

1. This unblocks #3464025: Remove Component config entity's add/edit form, which likely will be quite satisfying for @f.mazeikis to do :)
2. It also unblocks the follow-up #3469461: New component requirement: each SDC prop must have StorablePropShape, which will also help testing https://www.drupal.org/project/demo_design_system
3. This made me realize that we should do (the newly opened) #3469609: Prepare for multiple component types: ComponentTreeStructure should contain Component config entity IDs, not SDC IDs ASAP for a consistent data model.

This caused a regression: #3470550-10: Component config entities are incomplete: missing entries for optional props, causing errors in ComponentPropsForm.