Ensure deterministic version hashes for ComponentSource-specific settings, thanks to config schema-powered normalization

Overview

#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 brought versioned ComponentSource-specific settings: as either the component itself evolves (an SDC/code component gains new props, a block plugin gains new settings, the field type used for a particular SDC/code component prop shape changes, etc.), we'll be able to still access instances that were created for a previous version and keep those component instances operational.

Furthermore, this also allows storing less information in the ComponentTreeItem's inputs field property.

#3523841 introduced all the necessary infrastructure on the server side (a lot), optimized the storage of inputs for all GeneratedFieldExplicitInputUxComponentSourceBase-powered component sources, updated the client side (a little) to adjust for the changes, and hence kept it all working.

Part of that is:

If we take those scenarios as inputs, we should be able to create a determinstic hashing approach that gives us a unique version ID for each component and set of those constraints.

But that issue did notenable the validation that verifies the versions are indeed deterministic hashes. The logic for that already exists, but if we enable it, 110 tests fail.

So, clearly, the logic in \Drupal\experience_builder\Entity\VersionedConfigEntityBase::generateVersionStringForData() which uses

    $typed_data = \Drupal::service(TypedConfigManagerInterface::class)->createFromNameAndData($config_schema_type, $data);
    assert($typed_data instanceof Mapping);
    $normalized_data = $typed_data->toArray();

… does not quite result in the expected normalization that should result in deterministic hashes 😭

Proposed resolution

Investigate why the result of TypedConfigManagerInterface::createFromNameAndData()->toArray() is not deterministic.

User interface changes

None.