Proposal - Pluggable cache abstraction

[Hawxy]

Hiya,
I'm looking at building some more advanced abstractions around this package in order to automate feature tracking & checking in ASP.NET Core, but at the moment this package doesn't integrate well with the wider ecosystem.

Like many modern .NET projects, we already have a L1 + L2 + Backplane caching solution via FusionCache, and I'd prefer to reuse all of that infrastructure to keep our nodes in sync as it's far less chatty than a pure redis cache. At the moment there isn't an easy to way to swap out the caching implementation globally, and so that's what I've proposed here.

The main change is the cache abstraction is provided as a non-generic interface and reused where required, rather than having a cache per-type which doesn't scale well.

The existing RedisCache also had a few issues that've been fixed as part of this:

• ConnectionMultiplexer is designed to be created once for the life of an application and reused where needed, not created per-cache. Projects that are already using Redis will have a pre-configured Multiplexer and libraries typically let users provide one rather than dealing with the Redis connection themselves, so most of the connection options have been made obsolete.
• All of the I/O is sync when it should be async all of the way down.

Edit: I did another pass at the configuration options and aligned them with Microsoft's own Redis options for flexibility & familiarity.

[cbrady]

i don't think this test is valid anymore, i think it's passing because we can't determine if the background task removed the item or Get's lazy eviction did.

[Hawxy]

If that's the case it was always broken, right? Get previously had the lazy logic.

[cbrady]

this is looking good, one more thing. would you be able to update the readme?