Select configuration to enable on install

Thunder PR: https://github.com/BurdaMagazinOrg/thunder-distribution/pull/494

Problem/Motivation

Content list view:

• Normally Thunder ships a view with some content_lock depending fields. If content_lock module will be disabled, currently the complete view will be removed. A replacement view without content_lock fields should be in place then.
• We will ship a search_api integration as an optional module (thunder_search). If someone enables thunder_search, the content view should be replaced by a search_api based view. We should also be able to provide multiple search_api views. With or without content_lock and/or content_moderation. So in the end we will probably provide a content view for each possible module combination.

Proposed resolution

What we want to happen

1. When Thunder is installed the regular view is installed.
2. When content_moderation is installed the view with the extra content moderation features is installed.
3. When content_moderation is uninstalled the regular view is used.

Problems / thoughts

• On content_moderation install, what happens if the user has added important functionality to the regular view?
• On content_moderation uninstall, what happens if the user has added important functionality to the view with extra content moderation features
• Configuration snapshots or storing config somewhere else - how do we deal with code updates that make changes to configuration?
• Applying partial configuration updates - how to keep these in-sync with configuration changes due to code updates. How to reverse them? How do we deal with configuration that is changed

Ideas

In the views case we can just store different views in config/optional when content_moderation is installed the view which depends on it will be installed. At this point we would have two views that are enabled for admin/content. We could add third party settings to the views that would allow us to set a thunder name (which would be the same) and a thunder priority which would allow us to decide which one to disable and which one to keep enabled.

On uninstall we would have to work out if any configuration with a thunder third party setting is going to be uninstalled - if so we'd then need to activate the view with the next priority (as long as it is not being uninstalled too).

The following config entity types support disabling:

• block
• entity_form_display
• entity_view_display
• filter_format
• view

Remaining tasks

Make the new Configuration Selector module part of Thunder.

User interface changes

None

API changes

Data model changes