Don't invalidate the entire fast backend on persistent backend cache misses

Problem/Motivation

Every cache set and delete on the chained fast backend invalidates the fast backend.

However, there are two kinds of cache set:

1. A cache set that updates an existing cache item in the bin
2. A cache set that adds a new row to the cache bin

For #2, we don't need to invalidate the fast backend, because it won't have an entry to invalidate either.

The tricky thing is determining the difference between #1 and #2 but I might have an idea.

Steps to reproduce

Proposed resolution

When setting items in chained fast, first attempt to get cache items from the persistent backend. If any item is found, then update the last write timestamp, otherwise leave it as is. Because we're trying to get those cache items at the exact moment we'd otherwise be writing them, any potential race condition is essentially moot - the two cache items could conflict anyway.

While this means additional cache gets from the persistent backend when calling ::set(), it should more than reduce those overall when items can continue to be fetched from the fast backend.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet