Update code component props schema to support 'array' type

A great start! But I think the config schema is not yet correct. I think e.g. "array of URI strings" will fail to work currently.

@isholgueras see if this makes sense https://git.drupalcode.org/project/canvas/-/merge_requests/645#note_709202

Otherwise I think it looks good

Will review tomorrow AM. Let's land #3576578: Inform SDC/code component developers of nonsensical `type: array` prop restrictions: `maxItems <2` meanwhile.

Reflecting the complexity of this issue.

I have postponed #3572553: Save Multi-Value Prop Configuration for Code Components on this issue

Reflecting I'm pushing this forward, at @tedbow's request.

Turns out @tedbow and I battled with this previously, in #3509037: JavaScriptComponent config entities' `examples` and `enum` do not respect the prop's type. Almost exactly a year ago, even!

With the addition of wrapping any of the existing supported "prop types" (as we call them in the UI), the complexity grew significantly.

By the power of \Drupal\Core\Config\TypedConfigManager::getDefinitionWithReplacements(), this became a LOT better: 86484e51443a90818c0da6109c528f9f1681eb6e. We no longer need Canvas to work around #3577335: Config schema fails to expand dynamic non-top-level types, and we're using Config Schema As Intended™. (It follows the lead provided in #2392057-28: Config schema fails to expand dynamic top-level types.) Crediting @tim.plunkett because it's his test coverage that enabled me to step through and understand this!

However, we did end up trading one core bug (a new one) for another one (pre-existing): #3400181: Follow-up for #2663410: calling TypedConfigManager::getDefinition() causes cache pollution — this one is far more likely to get fixed, because there are literally @todos in core tests pointing to it and work-arounds for it!

CI is green: https://git.drupalcode.org/project/canvas/-/pipelines/761039 — but … the work-arounds in 3 places are inadequate: they only help PHPUnit tests, not CLI/E2E tests.

This is enough to make tests pass:

diff --git a/core/lib/Drupal/Core/Config/TypedConfigManager.php b/core/lib/Drupal/Core/Config/TypedConfigManager.php
index 99fdb0d5978..8e7b9921631 100644
--- a/core/lib/Drupal/Core/Config/TypedConfigManager.php
+++ b/core/lib/Drupal/Core/Config/TypedConfigManager.php
@@ -298,7 +303,9 @@ protected function getDefinitionWithReplacements($base_plugin_id, array $replace
       }
       // Unset type so we try the merge only once per type.
       unset($definition['type']);
-      $this->definitions[$type] = $definition;
+      if (!empty($replacements)) {
+        $this->definitions[$type] = $definition;
+      }
     }
     // Add type and default definition class.
     $definition += [

That should be the last bit 🤞

Wow @wimleers amazing work. I have not had chance to look through this but thank you so much!

Veeeery Nice to wake up to a green E2E test suite! 😮‍💨

Down to a single trivial failure and needing to merge in upstream. Already approved, now it’s up to Nacho & Ted to review my changes — but I think they’ll recognize the majority as being unchanged!

@Ted: you’re welcome! I knew this was hard-blocking y’all, so I tried to make it happen ASAP. This was one tough puzzle, but that’s why it nerd-sniped me 🤓😶‍🌫️😶‍🌫️

phpunit fail, but looks like a simple array key order problem. Working on it

Assuming tests now pass just a problem with array key order in test expectation, so back to RTBC

I think this looks good. there is one standing question from @ isholgueras https://git.drupalcode.org/project/canvas/-/merge_requests/645#note_713991 but I think to be practical we can follow-up with @wimleers on Monday.

Already responded :)

P.S.: you can confirm what I wrote visually instead of with a debugger using https://www.drupal.org/project/config_inspector

Thanks everyone!!!!

#3581581: Follow-up for #3568264: add explicit test coverage proving code components can have multi-value `enum` prop shapes improved this MR's test coverage.