Support installing all module configuration entities via recipes

Problem/Motivation

As a distribution maintainer, I'm excited to start incorporating the concept of recipes into farmOS. Our user base is farmers, and we provide a very flexible set of modules that they can pick and choose from, depending on what kind of farm they operate. Recipes feel like a perfect fit for providing pre-configured "sets" of modules and configuration. I'm imagining a custom UI that we can present to users (like a setup wizard) after installation that allows them to select one or more recipes to apply. These could be tailored to large row crop farms, small diversified vegetable farms, livestock operations, ranchers, orchards, beekeepers, etc etc. The way we do this now is we provide a list of modules that provide various components so they can turn on only the ones they need (eg: you only turn on the animal module if you work with animals).

I'm experimenting with this idea, and discovered that recipes do not automatically install configuration entities provided by the modules that it installs. This means that a "livestock" recipe is not as simple as this:

name: farmOS Livestock Recipe
description: Installs modules and configuration for livestock management.
type: farmOS
install:
  # Provides the "animal" asset entity bundle.
  - farm_animal
  # Provides the "birth" log entity bundle.
  - farm_birth
  # Provide a quick form for creating birth logs and animal asset entities.
  - farm_quick_birth

It needs to also explicitly declare all of the configuration entities provided by those modules AND all of the modules that those depend on. This quickly explodes into a potentially very large recipe.yml file that we need to maintain if/as changes are made in those modules.

I understand that recipes are intended to be explicit, specific, and declarative by design, but it seems like there could be an option offered for "simple" cases like this, where all of those decisions are already encapsulated in the modules.

That seems to be the spirit behind the wildcard * asterisk option, which you can use to install all the configuration in specific modules, but that still requires you to list all modules, and all dependencies of those modules that provide config.

In farmOS, the recipe above becomes this:

name: farmOS Livestock Recipe
description: Installs modules and configuration for livestock management.
type: farmOS
install:
  # Provides the "animal" asset entity bundle.
  - farm_animal
  # Provides the "birth" log entity bundle.
  - farm_birth
  # Provide a quick form for creating birth logs and animal asset entities.
  - farm_quick_birth
  # Provide a quick form for moving assets (eg: animal herds).
  - farm_quick_movement
config:
  import:
    # Install all configuration from the modules declared above.
    farm_animal: *
    farm_birth: *
    farm_quick_birth: *
    farm_quick_move: *
    # Install all configuration from all modules that are dependencies of the modules declared above.
    farm_activity: *
    farm_animal_type: *
    farm_location: *
    farm_map: *
    farm_log_category: *
    farm_observation: *
    farm_quantity_standard: *
    ... (and more)

However, this will also fail if any of those modules provide optional configuration that does not have its dependencies met. Normally, Drupal would simply prevent that configuration from being installed, but recipes don't work like that (see my related issue: #3560174: Filter out optional config with missing dependencies - Which means that the * wildcard option isn't actually an option for us, so we need to list (and maintain) all of the configuration entities for all modules and their entire tree of dependencies in the recipe.yml

This makes maintaining a list of recipes hard.

Granted, maybe "just installing modules" isn't a strong enough justification to use recipes. That is true, we could certainly roll our own solution for installing "sets" of modules and not use recipes. But I see other potential next steps that would leverage other recipe features, so I'd like to see if there is any interest/possibility of adding an option for simplifying recipe maintenance for this use case.

Thanks for reading and considering!

Proposed resolution

Can we add an option to recipe.yml that will allow the recipe author to say "install all of these modules AND all of their configuration entities, in the same way that they would be installed normally", instead of listing each module individually with an * to import all config.

And related: optional configuration should be filtered so that only the ones with their dependencies met are installed, like module installation works "normally". I opened a separate issue to consider this with the existing syntax: #3560174: Filter out optional config with missing dependencies

Remaining tasks

TBD

User interface changes

None.

Introduced terminology

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.