This removes Language::$dataCache without deprecation, because 1) I
don't know of a way to properly simulate it in the new paradigm, and 2)
I found no direct access to the member outside of the Language and
LanguageTest classes.
An earlier version of this patch (e4468a1d6b) had to be reverted
because of a massive slowdown on test runs. Based on some local testing,
this should fix the problem. Running all tests in languages is slowed
down by only around 20% instead of a factor of five, and memory usage is
actually reduced greatly (~350 MB -> ~200 MB). The slowdown is still not
great, but I assume it's par for the course for converting things to
services and is acceptable. If not, I can try to optimize further.
Bug: T231220
Bug: T231198
Bug: T231200
Bug: T201405
Change-Id: Ieadbd820379a006d8ad2d2e4a1e96241e172ec5a
The code previously here did not work well as it merely forwarded the
hash from the current web request. This had numerous issues:
1. It was often null because requests for stylesheets do not cary
a version hash.
2. When requested by JavaScript, the version hash would be a
combination-hash of many unrelated modules, thus when requested as
part of different batches, it would produce different urls which
is not ideal.
The impact of this is minimal currently because we basically never use
these urls, as SVGs are almost always embedded instead of ref'ed by url.
PNG urls are only generated for non-JS modules and then only used in older
browsers not supporting SVG. And, even after all that, for the edge case
of an SVG being ref'ed by url, they would be stored in LocalStorage by
mw.loader with the name+version of the module the image belonged to, not
the version hash of the batch request it came with.
Which means that, yes, localstorage key for "somemodule+someversion" would
have different values for different users, based on which batch the value
came with, because the image urls were using the version hash of the batch
request from ResourceLoaderContext. This is weird, but didn't cause bugs
or inefficiencies because the user would never be exposed to the other
possible urls for that image because we always check LocalStorage first.
It did cause fragmentation server-side in Varnish, though.
This is all fixed now by always including a version, and setting it to
the version of the module. This means there is no more Varnish fragmentation
for these. And it means that browsers are now allowed to cache the images
served from these urls for 30+ days (immutable) instead of only 5min,
which is what happened when they didn't have a version parameter (or set to
null).
Bug: T233343
Change-Id: I4af7fda03698ed4c288d154e7787fb2f3cbbe6c5
