This is a subtask of T223602 with a less ambitious and more iterative approach to get us in a better shape and have a better sense of what's in front of us. This should leave us in a state that is essentially a cleansed and easy to maintain and comprehend version of the status quo, which the parent task can then tackle further as only focussing on data format and location, with the rest of all the edge cases and problems already sorted out.
Below is result of @Ladsgroup and @Krinkle chatting at MediaWIki Hackathon 2022:
### Minimal scope
* Keep things fast to edit.
* Keep things fast to deploy.
* Keep using (for now) the same underlying system for storing and loading configuration from MW core and contributor perspective.
* Keep the same CI job and diff/preview features and confidence we get from that.
### Minimal problem statement
1. There should only one "right" place for a given setting.
Use case: Discovery, productivity, on-boarding, debugging.
2. Make config files more machine-editable.
Use case: Automate wmf-config patch creation when creating new wikis.
3. Remove most dynamic code and turn most such statements into pure data arrays.
Use case: Increase benefit of our CI diffConfig job. Currently it can't diff side-effects within CommonSettings.php and the other various complex PHP files.
Use case: Let CI assert there are no accidental overwrites or conflicts between the various wmf-config files that assign the same variable.
Use case: Prepare the repo such in the parent task we can figure out how we want to format and version this data for kubernetes, whether by injecting at pod launch time, or in some fast way from an image rebuild etc.
### Today
* `/wmf-config/CommonSettings.php`, the entry point from MW core Setup/LocalSettings, it essentially assigns `$wgConf = require IS.php`.
* `/wmf-config/InitialiseSettings.php`, is the almost-pure-data wgConfig structured array.
* `/wmf-config/*.php`, are mostly configuration but currently as executable statements. Most of these could be simple arrays in IS.php, but we keep them separate for easier browsing and editing, plus there's some wLoadExtension() statements.
* `/wmf-config/missing.php`, not configuration. This is a web entry point used by multiversion (it is also referenced by dead code in CS.php, **predating** multiversion).
* `/wmf-config/etcd.php`, defines functions, not configuration.
* `/wmf-config/import.php`, defines functions, not configuration.
* `/wmf-config/profiler.php`, preload init for PHP, not configuration.
* `/wmf-config/interwiki.php`, configuration data assigned in CS.php.
* `/wmf-config/ProductionServices.php`, configuration for `Wikimedia\MWConfig\ServiceConfig`, which is read in CS.php as `$wmgAllServices = ServiceConfig::getInstance()->getAllServices();`
### Proposed outcome
* `/wmf-config/CommonSettings.php`, entry point assigning `$wgConf = core.php + ext-FlaggedRevs.php + IS.php`.
* `/wmf-config/<component>.php`, pure data in StaticSiteConfiguration format, e.g. `core.php`, `ext-FlaggedRevs.php`, etc, split out from `IS.php`.
* `/multiversion/missing.php`, new place for missing.php.
* `/src/etc.php`, new place for etc.php.
* `/src/import.php`, new place for import.php.
* `/src/profiler.php`, new place for profiler.php.
### Steps to get there
* Minor change to IS.php from function to pure static array, and update require in CommonSettings.php.
* Create the first `/wmf-config/<component>.php` file with a handful of settings.
* In CS.php, read assign `IS.php + <component>.php`.
* Write PHPUnit test to assert there are no overlapping keys between these files.
* Slowly move non-config from current wmf-config/*.php files to wmf-config/CommonSettings.php (e.g. wfLoadExtension calls).
* Slowly move config from current wmf-config/*.php files to wmf-config/<component>.php.
* Slowly move simple config from CS.php to a relevant wmf-config/component>.php file.