Optionally apply configuration changes automatically

Big questions here are:

1. How do we know what config to maintain?
2. How/when/where do we maintain it?

> How do we know what config to maintain?

@pcambra pointed to the config_devel module as a possible example to learn from. They use a concept of "third party settings" in module info.yml files to define all the config that is "owned" by a module.

If we implemented something similar, we could essentially make a list of all the config items that each module manages, and the farm_update module could read that and only act on those config items.

Or, maybe that's not even necessary, maybe farm_update can auto-detect the config by looking at the config/install and config/optional directories directly.

> How/when/where do we maintain it?

The whole point of having this is so that we don't need to add endless hook_update_N() implementations for minor config changes. But hook_update_N() IS the easiest way to ensure this logic runs on updates, I think.

Alternatively, I wonder if hook_cache_flush() would work? Does that run every time that update.php is run? If so, then all we have to do is tell users to run update.php and it will update the config. But... I'm not sure if caches get cleared by update.php if there aren't any actual hook_update_N() implementations to run...

This related upstream issue in the config_rewrite module might be worth dusting off... IIRC it prevents "rewritten" config from showing as "overridden" in the configuration updates report.

I'm not sure if that would help with this issue at all... but if we need to be able to compare against "rewritten" config then maybe that provides some insight.

They use a concept of "third party settings" in module info.yml files to define all the config that is "owned" by a module.

I think this would make farm_update a dependency of all modules that include these settings, which would defeat the purpose of being able to disable it.

A hook is a simple approach that would keep this optional, and would allow modules to define config that they don't want to be updated. A similar approach can be taken with a simple config for the update module itself.

Alternatively, I wonder if hook_cache_flush() would work? Does that run every time that update.php is run? If so, then all we have to do is tell users to run update.php and it will update the config. But... I'm not sure if caches get cleared by update.php if there aren't any actual hook_update_N() implementations to run...

hook_rebuild() is another option (runs after caches are flushed): https://api.drupal.org/api/drupal/core!core.api.php/function/hook_rebuil...

Still an open question as to whether or not this runs via update.php even when there are no new update hooks. We could provide a Drush command to manually run the revert logic too.

This related upstream issue in the config_rewrite module might be worth dusting off...

We decided to remove config_rewrite from farmOS, so this is no longer relevant.

Opened a pull request for review: https://github.com/farmOS/farmOS/pull/444

This is causing farm_api tests to fail for some reason... commenting out farm_update in the base modules list in farm.profile fixes it. Needs more investigation...

Ah the tests are revealing some more config that needs to be excluded:

• user.role.anonymous
• user.role.authenticated

These were being overridden during the TokenBearerFunctionalTestBase. And in general we should not be reverting these two roles ever.

I also excluded system.performance.

Tests are passing now.

Merged.

There was some additional discussion in the pull request regarding triggering this via update.php, but I opted to just add instructions for clearing the cache after updating farmOS for now: https://github.com/farmOS/farmOS/pull/444