Audit usages of cache.static

Change the factory and use the faster memory cache implementation internally by default or introduce a new service that could utilize that as easy as the cache.static, but to use the faster implementation.

I think introducing a new service, maybe cache.memory, is the way to go. The reason cache.static is so slow, is because it uses serialize()/unserialize() to store its items. That's supposedly a feature, not a bug, because it means that the cache items can't be altered by reference (hence the name "static").

#1596472: Replace hard coded static cache of entities with cache backends was the issue that added the MemoryCache class, but failed to add a proper cache bin service for it. It only added the entity.memory_cache service, which is now probably being used in a number of places that it wasn't intended to be used.

#2973286: Clean up MemoryCache and MemoryBackend naming issues proposes to rename the classes to make their usage constraints clearer, but I think the more onerous problem is actually that there isn't a general service for MemoryCache and that core.services.yml doesn't have a good comment for cache.static. It just says "A special cache bin that does not persist beyond the length of the request." but it really should be more like its class docblock: "Should be used for unit tests and specialist use-cases only, does not store cached items between requests."

In context of serializers the most promissing looks #3014514: Make igbinary the default serializer if available, it saves 50% time on unserialize and memory footprint
But serializers/cache mostly blocked on #839444: Make serializer customizable for Cache\DatabaseBackend

@ndobromirov for me [de]serialize speed also makes sense when we tons of caches used

This is a really interesting issue, I'm not sure what the next steps are, but it seems like there should be a patch here first before we can mark it as needs work.

Intereting!

Doing the most bold approach to see what happens. NR only for the bot.

EDIT: Can ignore. Throws as of a wrong clone stmt.

Let's try swap out the static backend for the (badly named) entity.memory.

EDIT: Lots of breaks.

Try replace serialize w/ clone (+remove tag sort), to see what breaks.

Only few test breaks, and NO noticeable change in performance.

So it looks like:
- The originating issue found that cache.static is 3x slower than static class property caching (which is not tags aware) for some entity structures with many related objects. Fix was to use entity.memory_cache which does NOT serialize.
- Core since 8.6 uses entity.memory_cache, likely for same reasons
- The difference is, that cache.static does serialize and you get out a new built data object that is an exact copy of what you put in. The entity.memory_cache otoh gives you the same object, and if it was changed in the meantime, you get that changed version.

IF more optimizations are needed here, i can only imagine one route:
- Use https://github.com/myclabs/DeepCopy. And maybe we need / profit from a deep-clone-filter that takes __sleep / __serialize (and thus DependencySerializationTrait) into account.

I think i'm done here.

These should never have been added in the way they were IMO, but also probably predate the availability of MemoryCache as distinct from MemoryBackend.

Is there a reason not to use MemoryBackend instead of cache.static in the backend chain? I would think that would work.