ResourceLoaderStartUpModule: Use hashMtime to detect config changes
Changes to the static startup.js file are covered by the file
mtime in #getModifiedTime.
Changes to the module registrations are covered by the max
module mtime loop in #getModifiedTime.
But changes to LocalSettings.php etc. affecting mw.config values
embedded in #getScript aren't traceable. Resort to hashing those
and detecting changes between calls that way.
Without this, changes to mw.config never made it live (not even
after the rebuild every 5 minutes) because of 304 Not Modified
being sent between Apache and Varnish. Changes to config either
didn't matter to front-end right away and made it with the next
deployment that changes a different module, or by touching
startup.js to force a version bump.
Simple third party installs were not affected by this bug as their
settings would only be coming from LocalSettings.php (as opposed
to included files) and $wgInvalidateCacheOnLocalSettingsChange is
true by default.
Bug: 28899
Change-Id: I484166923d97368d95beeb40bb209dec9b849033