Problem/Motivation
The API for improving configuration management was added in #3047812: Add a Config Transformation event dispatching during config import and export to the experimental module so that it could be removed if there was no use of the API in core. Now there is (currently still part of the config_environment module) so we can move the API to where it should be.
Proposed resolution
Add a config transfomer API that allows event subscribers to edit the configuration just before it is imported or exported, knowing which it is and in which context the action is performed. In this patch we leave an @internal tag on the api to allow us to improve it.
We have one use of the api so far in core #3077504: Add config_exclude functionality to core and it will move out of config_environment as well on its own in #3079029: Move module config exclusion from config_environment to core.services.
Since that feature is stable and does not need to be behind a experimental module.
But we no longer need it in the potentially removable experimental module.
Remaining tasks
Move code to core namespace.
User interface changes
None, the API is transparent for users if there are no systems using it.
API changes
None but we can use the api without class aliases and without the config_environment being installed.
Data model changes
None
Release notes snippet
The config storage transformation api events can now be used without the config_environment module.
Original Motivation
The configuration management system in Drupal 8 is great and allows configuration to be synchronized between installations of the same site in different environments. This is done by exporting the configuration to an intermediary storage (files in git or tarball) transferring the intermediary storage and then importing it on the second installation. The ConfigImporter then takes the storage and checks for differences and updates the database to reflect the new configuration, creating or dropping tables etc.
However, the current workflow presumes that the configuration will be exactly the same in the different environments. If they are not, developers have to edit the configuration in the intermediate storage before it is imported again. The state of the art solution in contrib is Config Filter. It works great but has an important drawback as an API for both the DX and API architecture: It allows modifying the sync storage as it is manipulated but it has no concept of the intent. For example config filter plugins do not know if the sync storage is used for importing the configuration from it or exporting the configuration to it. A developer has to know which methods are called in which order of both the import and export process to correctly interact with it.
The concept of altering the configuration and importing it again is also used outside of the configuration synchronization process in contrib with Config Distro. The idea there is that the configuration importer can import the active configuration again after it has been modified by distro filters. This allows configuration to be updated with updated distribution configuration through the same ConfigImporter API but is not limited to distributions as such. Configuration can either be changed manually by calling methods on the configuration entities or it can be changed through importing all of the configuration through the ConfigImporter. The alter allows developers to change "arrays" and assures that all the appropriate side effects happen as they do when configuration is synchronized.