CommonSettings: Store mtime inside wmf-config cache file
Store the observed mtime of the input file within the cache value.
- Previously, the check used the mtime of the cache file, which is generally *after* InitialiseSettings.php is read, which means the cache mtime is is always the same or newer what the mtime of IS.php was when we read it. As such, the old code had to accept "cacheMtime >= actualMtime", but this meant it ignores any actual changes that may happen in between. This may seem unlikely if we assume no two deployments overlap, but becomes more likely when you consider that InitialiseSettings.php can edited or pulled from Gerrit much before a deployment starts. And, a web server only writes its cache during the first web request for a given wiki after the deploy (and some wikis may be accessed only rarely).
- When a config file is deployed with an mtime that is older than the mtime of the config file currently on a server, then it would be ignored. This could happen when using scap to undo a local change on a server, or if the clocks of the deployment host and local have drifted apart, or (in the future) if a deployed unit is rolled back to a previous version (right now with Git, a revert is a new commit and time generally always moves forward as mtime isn't committed, but in a Deployment Pipeline, a rollback or aborted deploy could actually restore older files).
- We have one less disk access (removed filemtime call).
To resolve later (unchanged):
- Stale config cache due to multiple changes within a second.
- Stale config cache due to changes that don't bump mtime.
These might be solved in a future change to using 'ctime' instead
'mtime', and maybe augment with file size (bytecount) as well,
e.g. from stat(). See also https://apenwarr.ca/log/20181113.