Add support for Sequentially constraint

Wow, am i dreaming. This little trick might make it possible to support those symfony constraints without weirdness.

Everything is green... It cant be that easy right?

Fixed issues, but kinda need someone into validation to review this since it feels weird this works at face value. It might overlook issues.

Removing tag since committer who will review this seems to be the subsystem maintainer.

Thanks quietone for the review. Since it was all style/wording ill set it back to RTBC

Valid point. As per parent Wim said he had a quite a few places where this was usefull, but he didnt say where. When i look at core i see a few places where this might be quite usefull. Few examples:

# file: block.schema.yml
    theme:
      type: string
      label: 'Theme'
      constraints:
        NotBlank: []
        ExtensionName: []
        ExtensionExists: theme

Here it could first say "Should not be blank", then if that is true "Invalid extension name", when "Extension does not exist".

This is way better than doing them all.

Same here:

# file: block.schema.yml
    region:
      type: string
      label: 'Region'
      constraints:
        NotBlank: []
        Callback: ['\Drupal\block\Entity\Block', validateRegion]

or

# Plugin \Drupal\ckeditor5\Plugin\CKEditor5Plugin\Language
ckeditor5.plugin.ckeditor5_language:
  type: mapping
  label: 'Language'
  constraints:
    FullyValidatable: ~
  mapping:
    language_list:
      type: string
      label: 'Language list ID'
      constraints:
        # Configuring this does not make sense without the corresponding button.
        CKEditor5ToolbarItemDependencyConstraint:
          toolbarItem: textPartLanguage
        # Only the following values are accepted.
        Choice:
          # United Nations "official languages".
          - un
          # Drupal's predefined language list.
          - all
          # Languages configured at /admin/config/regional/language for the site.
          - site_configured

I think a lot of the places where more than one constraint is defined we should use this. Should we pick one or perhaps just do follow ups? What do you think.

I've made #3544203: [META] Update schema's with multiple contraints to SequentiallyConstraint to start working on those after this issue.

https://drupal.slack.com/archives/C079NQPQUEN/p1763045170414389?thread_t...

Ok, with the help of @alexpott the issue has been fixed and we can easily support all the Composite constratiants now.

I've fixed the tests, which also seem to proove sequentially is doing its work, which is awesome :)

Think i adressed all issues, setting NR (tests are running, sorry)

As per 27 rtbc

I know this is rtbc, but when working on https://www.drupal.org/project/drupal/issues/3535734 i ran into wanting "Required" also a composite constraint. Then i realized, why don't we initialize the nested constraints (first level ) in the ConstraintManager?

   public function create($name, $options) {
     if (!is_array($options)) {
       // Plugins need an array as configuration, so make sure we have one.
       // The constraint classes support passing the options as part of the
       // 'value' key also.
       $options = isset($options) ? ['value' => $options] : [];
     }
     $instance = $this->createInstance($name, $options);
     // @todo If instance of Composite, initialize nested constraints?
     return $instance;
   }

Then i wouldnt have to overwrite the Required constraint to add extra logic to the create method... and it might be able to just load composites without any overwriting?

Updated the change record and added a new one.

It is kinda an API change, but the chance of breakage is pretty much zero.

Note about #13

Seems kinda hard. Not all composite constraints use the same property. The method to find out which property is the constraints is protected unfortunately which means we cannot know at that point which to use. A trait will work, but unless the method becomes pu b lic in symfony it's a no go without some bad magic.

Added comments, but only as indication of review. This looks very good, happy to see we don't need create anymore this way and we can add the symfony contraints easily. Still needs an overwrite of the existing constraint, which is unfortunate (and might proove very annoying when trying to implement the Collection constraint which hard codes new Required() sometimes. But it's a big upgrade on how this works.

Awesome, im happy. LGTM :D

Note, this blockes kinda blocks #3535734: Make block.settings.inline_block:* fully validatable, although maybe a soft block.

Found a possible issue when passing other options than constrainst to Composite contraints.

Talked to alex, creating a follow up.

#3558201: Composite constraints do not allow passing parameters

Awesome! Thanks