Make the chained fast backend self-heal when last_write_timestamp is missing

Something like this, will need some test coverage but want to see if any existing test coverage fails with this change.

Added unit test coverage.

Somehow managed to replace a test method instead of purely adding a new one - updated the MR and also kicking off the test only job.

Umm yes it should, obviously was thinking about the complicated comment and not the simple fix... Fixed that and added an expectation to one of the other test methods that would have caught it.

@kristiaanvaneyde so I think a more high level version of what happened in #3583040: Cache the container definition in APCu would be converting any regular cache bin to chained fast, where the container gets rebuilt, but the cache is not cleared. In that case, the persistent cache bin has a lot of warm cache entries, and the fast cache bin would be empty. Because there are entries in the persistent cache bin, there is no cache miss from the consumer's point of view, so nothing triggers a cache set. You'd get repeated writes to the chained fast backend, but no actual cache set until a real miss on the persistent backend too.

Another example would be an LRU cache eviction where the last_write_timestamp gets evicted but other cache items are left in the bin, which is probably impossible with a correct LRU strategy but bugs do happen and neither redis nor memcache would guarantee that frequently used cache items won't arbitrarily disappear.

I can't think of any other situations, so it should be extremely rare, and that's probably why it hasn't come up before. Also the worst side-effect here is APCu writes which are relatively cheap, so a site would see degraded performance if it happens, but maybe not degraded enough that they'd diagnose the problem before it fixed itself.