Config overrides not updated when config changes

BTW this used to be #1966538: Translation is not updated for configuration, when the config changes but that was closed since it was about to cover other things which became outdated. Now its a "simple" structural question.

Brought this to CMI meeting this week:

1. This is an API addition, not beta blocking.
2. Postponed on #2224887: Language configuration overrides should have their own storage since it implements override storage where save for overrides fires no events. Otherwise this is hard/impossible to implement because now language overrides are in general config and have events fired.
3. This could be implemented as a base class for overrides that would listen on save events and update its overrides.
4. Then language overrides would extend from this base class instead of just implementing interfaces.

Marked as beta target because this API addition would be nice to do before beta so modules can extend from that. Eg. domain module for its overrides.

#2224887: Language configuration overrides should have their own storage is definitely in, so we can unpostpone this.

vijaycs85 says he is working on this.

I don't see how this will react to config data changes, maybe I'm not clear on something getOverride() does to ensure this? The rename and delete reactions look complete though. Besides missing tests, I only found this minor issue:

+++ b/core/modules/language/src/Config/LanguageConfigFactoryOverride.php
@@ -208,9 +208,52 @@ public function addCollections(ConfigCollectionInfo $collection_info) {
+    $config_translation = $this->getOverride($language->getId(), $name);

Not indented properly.

Fixed the indent and a comment and added a start for some tests. Although locally untested :D

Decided to not modify the existing test because it deals with overrides for config not yet saved. Would have needed to modify it too much to be good for this other use case, so just added more test data for the new use case. Cleaner. Should theoretically have less fails, since we were testing things that were not appropriate for both scenarios when reusing the older test code.

The first fail was due to bad test :) Was about ensuring the original data was removed. Fixed that. The other fail proves the language override is in fact not updated when the original data changes. :) Just as I theorised in #10.

I think this is about the solution to the problem. As discussed before we need to filter the override based on the original config. I think we'll need this as utility methods, so added to ConfigFactoryOverrideBase.

Improved the test in two ways:

1. Made the override use a nested key element not on the top, so e can test that if that is removed in the data, the whole override container data structure is removed if empty.
2. Added a French override as well that uses less data and therefore disappear sooner, when it does not contain data anymore. Added tests for that.

With improved type hinting and phpdoc. I consider this ready.

I don't think either vijaycs85 or myself are qualified to RTBC this one, so assigning to alexpott.

Yeah it makes sense to check for new-ness of the override (whether it actually exists or was just created). Also using the same logic in the other places to ensure consistency.

As for the applicability of the base class I think there is good value in both unifying the event listener methods (this is done a lot in Drupal 8 elsewhere) and also the generic override filter methods are applicable regardless of the override itself, whether it is domain based or og based. So those modules can use the same base class and feed their overrides to the filter code. I originally thought we would go as far as to implement this even outside the concrete override classes and on the collection storage level, assuming all storages but the default storage are overrides, but that may or may not be a good assumption. Then we would not need to do custom code for each override type to enumerate its (possible) list of overrides for a key. This is the main thing I guess I would love to get feedback from alexpott as well :)

Making the utility methods protected instead of static based on in-audio meeting review with @alexpott.

1a. All right, I think overide => override was fun, but I can see how that may be confusing. Now renamed to 'foo' => 'bar' to make it clear. It does not name the original override then :D

1b. As for how the override was first before the config, that was to avoid needing to manually clear the config factory cache :D Now I moved the original before the overrides, and now clearing the cache, so we don't get the non-overridden version from the cache.

2. Removed.

Amazing, thanks.