eca_content - "Entity: load" action: Use Drupal states library

Adding potential blocker.

There is no blocking dependency here, not even a dependency at all. The config form for this action should and could be improved with better UX by utilizing all useful features from Drupal's form API is a thing, whether bpmn_io is going to be using this or not. This action is (potentially) used in different contexts, i.e. in eca_cm and maybe other places. If the context is built upon the form API, then improvements to the build form will improve that. Other usage context, like e.g. bpmn.io so far implements configuration by downgrading forms to their current feature set. And that continues to work, even if the form config gets improved here.

This is important to keep things decoupled from each other moving forward. I treat that as one of the key design decisions for the ecosystem.

Added #states to form elements on entity loader service and entity load action.

This looks great, only found a couple of improvements and one mistake: the token name is always required.

In addition to that, I wonder if the field Entity at the bottom of the form should also only be visible when the from field is set to current?

A form error is triggered if entity type is required, but none is selected. However, I can not get the corresponding form field to be highlighted. #array_parents in \Drupal\Core\Form\SubFormState::setErrorByName() does not seem to match with the entity type form field name.

I think you can set the form error like the following:

$form_state->setError($form['entity_type'], $this->t('Select the entity type to load.'));
The Form API then should take care about properly identifying the form element.

I took a look into the MR and noticed the following regards the #states instructions:

name="action[from]"

It should be noted, that the first key action is coming from the concrete implementation of eca_cm. The Core Modeller module embeds plugin forms, and prefixes them with the type of plugin (event/condition/action). That means, the currently implemented #states instructions may work for eca_cm, but it's not guaranteed that they will work for other modeller implementations. As we haven't a concrete implementation for 🌱 [meta] Replace property panel with Drupal Form API Active yet, I'm currently not able to find a proper mechanic, which guarantees the compatibility across different modeller implementations.

I took a look into the MR and noticed the following regards the #states instructions:

name="action[from]"

It should be noted, that the first key action is coming from the concrete implementation of eca_cm.

I'd say the plugin config forms should be declared for "standard" usage, i.e. as if it were used directly by e.g. a form in core. If one of the modellers needs to adjust that, it should be the modeller's responsibility to alter the forms.

To summarize, I think we're fine when following aspects are covered:

1. The form error needs to be set properly. This can probably be achieved with sugesstion mentioned in #10.
2. Resolving the parent key problem that was mentioned in #10.

For point 2, the following approach may work:

The buildConfigurationForm method of each plugin receives a $form array argument. In that array, eca_cm always passes along the '#parents' key, which contains an array of the parent keys in the form. By extracting the #parents, prepending them to the form input key for each #states entry, you then have the addressed form input. This could be a general mechanic to be applied, because the #parents key is a key concept of Drupal's form API. Meaning, when implementing Drupal form API for BPMN_io, it can also pass along the #parents key to the buildConfigurationForm method.