Deleting optional props from an SDC/code component causes validation errors in config-defined component instances: regression for monolingual sites, bug for multilingual sites
The following [discussion](https://git.drupalcode.org/project/canvas/-/merge_requests/1271#note_1273034) from !1271 should be addressed:
> :warning: :exploding_head: While sprinkling `self::assertEntityIsValid(…)` calls over @tedbow's a41099c6d32b6e13296eb0325b1a94cf8ef14b16, this was a highly unexpected find!
>
> This means #3591667+ would be surfacing validation errors for many component trees using `sdc` or `js` component instances that have had optional props removed.
>
> Fixing it is out of scope here; needs follow-up.
### Problem
Removing an optional prop from an SDC/code component (which triggers a new version for the corresponding `Component` config entity) causes **validation errors for a previously valid-and-completely-unchanged config-defined component tree.**
### Root cause
1. #3582478+ introduced `ComponentInputsMapping`, to allow for translations of config-defined component trees
2. :bulb: But this also ensures stricter validation for _all_ config-defined component trees! (Also on monolingual sites.) This improves DX, because for example exported config-defined component trees gained predictable ordering of `inputs` in each component instance.
3. It calls `JsonSchemaPropsComponentInstanceInputsConfigSchemaGenerator::getConfigSchemaMapping()`
4. Which calls `JsonSchemaPropsComponentSourceBase::getExplicitInputDefinitions()`
5. Which calls `JsonSchemaPropsComponentSourceBase::getMetadata()`
6. Which for both an SDC and a code component can only return the metadata for the _live implementation_: the JSON schema for each prop that is stored in an SDC's `*.component.yml`, or in a code component's `JavaScriptComponent` config entity
7. :bug: ⇒ **The mapping computed by `ComponentInputsMapping` does not actually respect the component version: it always uses the live/deployed JSON schema!**
<details>
<summary>How does this relate to translations?</summary>
The original purpose: `::getConfigSchemaMapping()` in 3. _uses this JSON schema to determine which inputs ("props") are translatable, and sets config schema's `translatable: true` on whichever inputs ("props") have a JSON schema definition that is translatable — for example `type: string` is, and `type: boolean` is not.
</details>
### End-user impact
- :green_circle: Low, because automatic component instance updating (`ComponentInstanceUpdaterInterface`) automatically fixes it
- :yellow_circle: Medium, because #3591667+ will surface lots of validation errors that are more noise than value, although auto-component-instance-updating will trivially fix it.
### Proposed solution
Expanding what `type: canvas.json_schema_props`'s `prop_field_definitions` stores: either add
1. `translatable: { type: boolean }`
2. `json_schema: { type: ignore }` ← raw, originally defined JSON schema
3. `shape`: { type: ignore }` ← normalized JSON schema, see `\Drupal\canvas\PropShape\PropShape`
This would then enable `JsonSchemaPropsComponentSourceBase::getMetadata()` to return the _version-specific metadata_, instead of the _live/deployed metadata_.
> Change record: [#3608942](https://www.drupal.org/node/3608942)
> Change record: [#3608946](https://www.drupal.org/node/3608946)
issue