Centralize chained fast bin invalidations to reduce consistent backend lookups

Talking to @longwave in slack one issue with checking things once at the beginning of the request is it brings forward the point where the semaphore could start to be stale - e.g. if a cache bin is invalidated after the semaphore is retrieved then the request wouldn't notice, but it might if the cache bin was looked up a bit later.

For chained fast we set the timestamp into the future when it's invalidated to account for this (at least for a normal-length web request), so we could do the same with this - use a timestamp and check it's in the past as well as it matching what's stored in APCu.

This can't work - the items in the chained fast backend can be older than the bin invalidation, that's why we have to check it. So if they're older than a global semaphore is, we'd still need to check the individual bin invalidation timestamp or look them back up anyway.

#3 was correct that the original idea won't work, but then I realised it can work if we keep the individual bin invalidation timestamps in APCu too.

And then - what lets you store things in APCu and a consistent backend, with a single lookup allowing multiple keys to be fetched from APCu - chained fast backend!!!!!

MR is up.

The only alternative name for CoordinatedChainedFastBackend I have is ChainedFastChainedFastBackend.

Performance tests look superficially worse but show it working - for each chained fast backend, there's now a look up against the invalidation backend bin, which should hit APCu (+ 1 check against its own consistent backend).

Haven't added explicit test coverage here yet, but hoping for a green pipeline on existing tests.

So what happens with this is the bootstrap, config, discovery and routes chained fast cache bins in HEAD each have to look up last_write_timestamp in their persistent backend once per request.

With this change, we move the last_write_timestamp checks to a separate, single, chained fast bin.

That chained fast bin will look up it's own last_write_timestamp entry in the consistent backend, and then it uses the chained fast logic that we already have to determine whether it needs to hit the consistent backend for the other bin timestamps.

The result should be instead of 4 persistent backend lookups, one persistent backend lookup + 4 APCu lookups.

If there's been an invalidation, it will be 5 persistent backend lookups instead of 4.

@longwave's point in #2 is still correct but not sure it makes a lot of difference in practice - anything which fetches something from cache just before it's invalidated then static caches it has the same issue, this increases the window for that slightly.

With the discovery and routes caches nothing writes to those dynamically anyway as such - they get fully invalidated then repopulated.

The bootstrap cache is more dynamic, but is retrieved very early in the request anyway so the timing would not be much different.

Since this doesn't show up in performance tests, because we log cache operations at the level of the bin rather than the individual cache implementations, I profiled the front page of the standard profile, with page_cache module uninstalled and logged out - e.g. a dynamic page cache hit.

Found one bug - with a return type hint of float we need to check for missing invalidation timestamps against === 0.0, added the return type hint to the parent class too since it's protected for consistency.

This reduces database cache gets for that dynamic page cache hit from 14 down to 11. This is because we get (at least) routes, config, discovery on dynamic page cache hits.

Missed the 'before' screenshot.

Rebased.

Rebased.

Rebased.

Rebased.