[META] Implement complete coverage of validatable config schema across plugins and entities

Thank you @michaellander for cicking this of. I'm in full support of this idea and also added a related issue at 📌 Config validation for ECA models Active which was triggered by Wim Leers when he first saw ECA in action.

In that related issue, @lammensj already got started with schema improvements for ECA config parts that are not yet down to the plugin level. Compared to the plugin level, that's probably the easier part, but still also very important.

That leads me to the one big question mark that I can't get my head around to yet: when each plugin has its own schema being defined, that doesn't do much yet in terms of validation or improving the reliability. This is because the configuration for an individual plugin will never be stored as config at any time. The only exception would be if the action UI module were used where one could preconfigure actions for later use. But that is a very uncommon way and that module was just recently extracted from Drupal core and doesn't see much maintenance: action module → .

When ECA saves an ECA model in a config entity, that is constructed of the parts that are being worked on in the related issues followed by a list of plugins, each of which having a configuration property that contains a simple list of key-value pairs.

If we wanted to cover that part in the ECA schema as well, we would have to have an aggregate of all the plugin schemas in the ECA schema. Or is there a way to refer to the plugin-specific schema by the plugin ID, including for all those unknown plugins that come from contrib modules?

If we wanted to cover that part in the ECA schema as well, we would have to have an aggregate of all the plugin schemas in the ECA schema. Or is there a way to refer to the plugin-specific schema by the plugin ID, including for all those unknown plugins that come from contrib modules?

You only need to define schema for the actions you are defining, and then you are correct, you can just have an argument for the plugin_id to handle all actions, irregardless of if they are in your purview.
Here are a few Action schema snippets from core:

//from web/core/config/schema/core.entity.schema.yml
action.configuration.action_send_email_action:
  type: mapping
  label: 'Send email configuration'
  mapping:
    recipient:
      type: string
      label: 'Recipient'
    subject:
      type: label
      label: 'Subject'
    message:
      type: text
      label: 'Message'

and

//from web/core/modules/user/config/schema/user.schema.yml
action.configuration.user_add_role_action:
  type: mapping
  label: 'Configuration for the add role action'
  mapping:
    rid:
      type: string
      label: 'The ID of the role to add'

Which would be covered by:

   type: action.configuration.[plugin_id]