Right, so usually config.php is used for the key data/db/url settings but it also allows for settings which can usually be edited in site admin to be overriden & enforced. That's usually something which might be done for a couple of settings for security purposes - e.g. preventing cron from the web from being triggered by anyone.
I am however considering using this mechanism to it's fullest extent to deal with moodle configuration management across all our test to prod environments, versioning with peer-review, etc. Would also allow us to ensure that when a plugin is deployed the associated configuration we want for it is deployed in one go - for example with a highly configurable theme, one could ensure every single setting gets set correctly from the get go rather than re-doing all of this manually and that this goes through our CI/CD pipeline, changing all of the environments consistently. Now, I had thought we could do that by inserting the configuration into the database table but doing it through the config.php seems much better suited and much easier to script.
Assuming that once put together, that would be in the 1000s of lines of config. Has anyone else done this? Any impact on performance to expect?
I guess it should reduce queries on the DB and increase(?) memory usage on the app servers - though most of this ends up being cached anyway so it probably shouldn't make a difference either way.