Optimize last_write_timestamp writes in ChainedFastBackend

Problem/Motivation

With a completely cold cache, immediately after drush cr, there can be hundreds of writes to the persistent cache backend to record the last_write_timestamp.

With stock Drupal CMS, profiling with xhprof, I saw 145 persistent cache writes from ChainedFastBackend::markAsOutdated().

I think we can optimize this case quite significantly by setting the initial write timestamp 50ms ahead instead of 1ms when we actually write it, but then only writing to it again if the current timestamp is > 1ms.

What this means in practice is that we write the last_write_timestamp a maximum of every 50ms in a single request.

This means that other requests may treat chained fast cache items as invalid for 49ms longer, but that is only the case if there is a single cache write. If we're invalidating every millisecond for 50ms, then other requests still get constantly invalid items until the cache writes stop.

Also, the very last invalidation during a request will be between 1-50ms ahead, not always 50ms, depending on whether the last few cache writes need to write to the persistent backend or not - so the minimum time from the last write to the first successful fast backend get is still 1ms overall.

In my testing, this reduced 227 persistent cache writes to 47, a reduction of over 3/4.

#2611400: [meta] ChainedFastBackend should not invalidate the whole fastBackend when doing a Set() has some related discussion but is very out of date and this particular approach did not come up in there.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet