[meta] Make recipes safer to use in the real world by supporting config validation and rolling back a broken recipe

Problem/Motivation

When you apply a recipe to your site, there is no real promise that it will work. For example, a recipe can ship invalid config, or it can ship config that conflicts with other config in insidious ways.

That's bad enough, but what's really uncool is that, if a recipe does blow up while being applied, it just leaves a mess - some config has been modified by the recipe, other config hasn't, and you're stuck in the middle. If you didn't make a backup before applying the recipe, you're in trouble.

What this means is that recipes, as they exist right now, are unsafe to use except in controlled conditions, by people who know what they're doing. They are definitely not safe for production. The inability to know whether a recipe is shipping valid config is an obstacle to creating recipes that other people can use.

Our aim in this issue (and its children), then, is twofold:

1. Do what we can to ensure a recipe is shipping sane and safe (this usually means "valid") config.
2. If a recipe breaks while applying, ensure that the recipe runner doesn't leave a colossal mess behind.

These two things would go a very, very long way towards making recipes safe to use in the real world.

Remaining tasks in this project

These are in priority order. Postponed issues are blocked by issues either in core, or further up in the list.

We can start validating config as we create it. We need to validate it one piece at a time, because config validation constraints sometimes depend on other config already existing.

1. #3401925: [PP-2] After a recipe is successfully applied, validate all of the config that was imported or modified by config actions will validate all config after the recipe is applied, as a final check.

In both of these issues, any validation error will cause the recipe to fail, and config to be reverted.

Completed tasks in this project

• #3425540: Only validate config which is fully validatable
• #3401723: Config modified by action plugins should be validated after it is saved will validate config modified by config actions.
• #3401867: Validate config that gets imported from modules or the recipe's config directory
• #3416287: ConfigConfigurator should be insensitive to key order when comparing active config to recipe config
• #3407956: Create a config storage checkpoint before applying a recipe
• #3390919: Create a config storage backend that can set "checkpoints", recording the changes to config that happen in between them

Remaining tasks in core

There are two "tiers" of work that has to happen in core - hard blockers, and issues that we need to land in order for this to be useful.

Hard blockers

None right now.

Issues we need to land in order for this to be useful

None of these issues are blocking us, but until they land, config validation in recipes is relatively useless.

None right now.

Fixed (in core)

• #3395099: [meta] Allow config types to opt in to config validation, use "FullyValidatable" constraint at root as signal to opt in to "keys/values are required by default"
• #3364108: Configuration schema & required keys
• #3379091: Make NodeType config entities fully validatable
• #3406478: Refine ValidKeysConstraintValidator's messages: use #3401883's new Mapping infrastructure
• #3364109: Configuration schema & required values: add test coverage for `nullable: true` validation support
• #3405800: Config collections do not trigger configuration events consistently
• #3404023: DefaultSingleLazyPluginCollection::setConfiguration() accepts NULL but ConfigurableInterface::setConfiguration() does not