Define recipe runtime configuration update requirements

Problem/Motivation

As well as #3283827: Support multiple config update paths → , which covers what happens after a recipe is applied, there are recipe runtime considerations.

We're trying to give a recipe comprehensive control over the specific configuration it installs. When a recipe is applied, it may attempt to install configuration that's already present on the site, but in a previous (potentially customized) state. How should that work?

Another way to frame this question is: how does it work when a recipe is re-applied?

This is particularly likely as recipes are composable. It's expected that a few commonly used recipes will be reused by many other recipes, meaning it's usual that when a particular recipe is run that some of the recipes it requires will already have been run and configuration provided by the recipe will already exist, albeit potentially in an earlier state.

The questions apply both to extension-provided and recipe-provided configuration.

For example, say that Recipe A is applied. It directly provides several configuration items and also installs several configuration items as provided by Module X.

Time goes by, during which the site builder makes various tweaks to the configuration originally provided by Recipe A and that from Module X.

Now Recipe B is being applied, which requires Recipe A. In the meantime, the configuration Recipe A directly provides has changed a lot. There are new items, some of the old items are no longer provided, and previously existing items are in a changed state. Ditto for the configuration Recipe A selects from Module X--Recipe A now installs some new items from Module X, doesn't select some it used to, and some of the items it still provides are in a changed state (that is, they've been updated since the time the site first applied Recipe A).

What should happen?

With newly newly-provided config it seems straightforward: install it.

Config that used to be provided? Rather than delete it, probably just leave it in the active config.

But for config that was already installed, the case is more complex. Some possibilities:

1. Configuration provided by the recipe is left at its current state (as originally installed plus any changes made by the site builder), regardless of whether there have been changes (updates) in the config as now provided.
2. Configuration provided by the recipe is updated (reverted) to its current state as provided by Recipe A, losing any customization the site builder may have made.
3. Changes to the configuration as provided are merged in and saved to the active config in a way that respects customization.
4. The recipe throws a validation exception and is not applied.

The answers may be different for recipe-provided config vs. extension-provided config. Depending on the answers, there may or may not be additional scope not yet captured.

For example, as well as implications for the way config is created or updated, it may be necessary to track which extensions were originally installed via recipes, and which recipes were previously applied on a given site.