From @sbelyshkin in the linked PR:

When using TagAwareAdapter with volatile caches such as Memcached and Redis with 'alkeys-lru' eviction policy, eviction of any key may happen.

Currently, tag-based invalidation is achieved by incrementing tag version numbers starting from 0. The 0th version is assumed by default and is not even stored in the cache, only non-zero versions are stored. Because of that, when a tag version key is evicted from cache, version counter is "reset" to 0, and if there are items still stored with tag version 0 (had not been accessed/updated by the moment of tag eviction), such items become valid again while must be deemed invalidated. Similarly invalidation may be lost when tag is invalidated particular number of times after its eviction (for items with non-zero tag version).

This scenario is more likely for item-tag pairs which are accessed and invalidated less frequently than others (due to LRU policy and lower version numbers) but this measure is quite relative. LRU caches implement different algorithms (e.g. https://redis.io/topics/lru-cache, https://memcached.org/blog/modern-lru/) and free to evict any key of their choice so even a tag which is accessed or invalidated pretty frequently can be evicted when LRU cache is full and under havy loads.

In order to prevent invalidation losses, any non-repetative numbers can be used as initial value for tag versions.

This PR goes one step further and borrows from #42997: instead of incrementing the version number on invalidation, we delete the value from the backend, and recreate it when needed with a random offset.

This PR also removes auto-commit on tag-invalidation: this behavior adds complexity, is not needed and is not consistent with Redis|FilesystemTagAwareAdapter.

/cc @sbelyshkin can you please give it a go in a review?