Make Block config entities fully validatable

Repurposing this to add validation constraints; the original issue summary no longer makes sense because the scope/approach of 📌 Configuration schema & required values: add test coverage for `nullable: true` validation support Fixed evolved.

Well this is interesting… AFAICT block.block.*:provider is dead/completely unused, but block.block.*:settings.provider is used.

Ah, I finally found the explanation for why status, info and view_mode are part of the generic type: block_settings (and hence apply to ALL block plugins!).

The answer: it's simply an oversight that occurred in #2274175: Block plugin schema should be defined separately from the entity → . 😄👍 (\Drupal\block_content\Plugin\Block\BlockContentBlock landed >1 year earlier, but the tight coupling only was removed ~6 months earlier, in #1927608: Remove the tight coupling between Block Plugins and Block Entities → . Arguably at least there this should've been rectified, but that was at the height of the "we must get D8 done yesterday!" era, so it totally makes sense.)

So this issue is definitely cleaning up some very old technical debt, that's caused confusion for every person who has ever looked at the exported YAML for blocks! 🚀

Great find! Would be great to have CR for that change somehow as I bet some contrib already using the same pattern

#6: this will absolutely need a change record — probably multiple!

Wow, with #5 fixed, plus one small fix to the ExtensionExists constraint, we went from 788 failures to 115 failures! Suddenly this became doable 😄

Yay, and after refining the constraints for the sole block (the search block) whose settings I've added validation constraints to: 115 → 56 failures.

Reduced scope by:

1. Undeprecating the (unused and useless) provider exported property in Block config entities around dropped us to 52 failures
2. Undeprecating the status and info settings for "content block" blocks dropped us to 51 failures

Rewrote issue summary 👍

GREEN!

Update path tomorrow.

Very satisfied that I got this to green with just 18 files, +138, -49 in less than a day 🥳🚀 With this in, we could seriously accelerate config validation adoption, and Recipes indirectly!

2 of the 3 follow-ups created.

Update path test pushed.

Update path pushed.

3rd follow-up created (with MR!).

Two blockers created:

• 📌 Add config validation for weights (blocks, filters, etc. all use weights) Fixed
• 🐛 ExistsConstraintValidator should ignore NULL values and treat `core` as a valid module Needs review

… both with a ready-to-review MR that's green. 😊

Ready for final review! But please help land the two (trivial!) blockers first 😄

📌 Add config validation for weights (blocks, filters, etc. all use weights) Fixed is in! Will update this MR in the morning.

Next up: 🐛 ExistsConstraintValidator should ignore NULL values and treat `core` as a valid module Needs review .

The Needs Review Queue Bot → tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide → to find step-by-step guides for working with issues.

MR now on top of 📌 Add config validation for weights (blocks, filters, etc. all use weights) Fixed 👍

🐛 ExistsConstraintValidator should ignore NULL values and treat `core` as a valid module Needs review is in too.

Will update this MR.

I found one tiny nitpick.

I started added explicit validation logic for all of the properties on Block config entities. I just pushed the test coverage for theme.

But then I noticed that block.block.*:region doesn't have a validation constraint just yet! So this definitely needs more work before it is ready for final review. Will continue this next week.

Marked NR for initial review.

This is looking good but still needs some changes...

A few questions but overall I think this looks pretty good.