Deterministic Component version hash should depend not only on source-specific settings, but also slots + explicit input schema

Overview

As of #3523841: Versioned Component config entities (SDC, JS: prop_field_definitions, block: default_setting, all: slots for fallback) + component instances refer to versions ⇒ less data to store per XB field row, a new Component version is created whenever the ComponentSource-specific settings for that component change.

For SDCs and code components, that's prop_field_definitions:

    $version = ComponentEntity::generateVersionStringForData($settings, 'experience_builder.component_source_settings.sdc');

and

    $version = ComponentEntity::generateVersionStringForData($settings, 'experience_builder.component_source_settings.js');
    $component
      ->createVersion($version)
      ->deleteVersionIfExists(ComponentInterface::FALLBACK_VERSION)
      ->setSettings($settings);

But … shouldn't a new version also be created when the set of slots changes? Otherwise, a change in slots doesn't cause a new version to be created? (Realized this while reviewing #3519891: Constrain slot names allowed by XB in Components (and in its component tree).)

Otherwise, we can end up in a place where the Fallback source (introduced in #3519168: Handle components provided by ComponentSources EXPLICITLY disappearing — enables deleting JS components that are in use) won't be able to know the actual slots available for a particular version of the component: as long as the props of an SDC/code component remain the same, we'd end up overwriting the information in fallback_metadata.slot_definitions for that same version.

Proposed resolution

Update the logic to let the following affect the deterministic hash (actually deterministic since #3528159: Ensure deterministic version hashes for ComponentSource-specific settings, thanks to config schema-powered normalization):

1. ✅ ComponentSource-specific settings
2. ✅ normalized slots: the result of ComponentSourceWithSlotsInterface::getSlotDefinitions() but without the description and only keeping the first example
3. normalized explicit input schema:
   • ✅ the result of \Drupal\experience_builder\PropShape\PropShape::normalize() for SDC + code components, plus with the default value (i.e. the first example) ⇒ ⚠️this is strictly speaking not necessary for these component sources thanks to prop_field_definitions being part of the settings
   • ✅ the combination of a normalized config schema for that block plugin , plus the block plugin's ::defaultConfiguration (default values end up in type: experience_builder.component_source_settings.block)

The deterministic nature of the version hash must be validated, by validating the active_version. But older versions should not be validated, for the reasons outlines in #12.

IOW: this is necessary for #3524751: [later phase] Component Source plugins: generalized support for schema changes of explicit inputs to be possible without BC breaks. Now that many pieces exist, it's clear that this part that was descoped at #3520484-44: [META] Production-ready ComponentSource plugins actually is necessary. (This used to be mentioned in the data storage IS until a few weeks ago — see for example @longwave's comment at #3520449-17: [META] Production-ready data storage).

This should be easily manually tested to verify the expected real-world impact from a component developer POV (the example used is the block component source, but this should work equally well for SDC etc.):

1. Go to /admin/config/development/configuration/single/export and export block.system_menu_block.tools
2. Modify e.g. level in \Drupal\system\Plugin\Block\SystemMenuBlock::defaultConfiguration(), then rebuild.
3. Repeat step 1 and observe: a new version, with a new default value in default_settings.
4. Now go and modify block.settings.system_menu_block:* and add a new optional key-value pair, for example:
   

   diff --git a/core/modules/system/config/schema/system.schema.yml b/core/modules/system/config/schema/system.schema.yml
   index 0c7cfac313c..d38a75778ff 100644
   --- a/core/modules/system/config/schema/system.schema.yml
   +++ b/core/modules/system/config/schema/system.schema.yml
   @@ -448,6 +448,9 @@ block.settings.system_menu_block:*:
        expand_all_items:
          type: boolean
          label: 'Expand all items'
   +    yar:
   +      type: boolean
   +      requiredKey: false
    
    block.settings.local_tasks_block:
      type: block_settings
   

5. Repeat step 1 and observe: a new version, with the same default values in default_settings, but … a new version, because config schema has changed.

User interface changes

/admin/appearance/component now shows the number of versions of each component, and shows the active version upon hover.