If PoolCounter acquisition would block and a stale ParserCache entry is
available, deliver it immediately rather than waiting for the lock. This
should avoid PoolCounter contention on heavily edited pages.
* Add a fastStale pool option to toggle the feature. False by default
but I'll set the default to true in a followup commit.
* Add a $timeout parameter to PoolCounter::acquireForMe() and
acquireForAnyone(). This requires a simultaneous update to the
PoolCounter extension.
* In the Redis implementation, use the requested timeout for blPop()
but use the configured timeout for data structure cleanup and item
expiry.
* Add a boolean $fast parameter to fallback() which tells the subclass
whether it is being called in the fast or slow mode. No extensions
in CodeSearch extend PoolCounterWork directly so this should not
cause a fatal.
* Pass through the $fast parameter in PoolCounterWorkViaCallback
* In PoolWorkArticleView, use the $fast flag to decide whether to check
the ChronologyProtector touched timestamp.
* Add $wgCdnMaxageStale by analogy with $wgCdnMaxageLagged, which
controls the CC:s-maxage when sending a stale ParserOutput.
* Fix the documented type of the timeout. It really should be a float,
but locks.c will treat non-integers as zero.
A simultaneous update to the PoolCounter extension is required.
Bug: T250248
Change-Id: I1f410cd5d83588e584b6d27d2e106465f0fad23e
7f710a514a