[FEATURE] 🔒 Extensible Distributed Locking

[jodydonetti]

Problem

As explained in #574 , I'm introducing a new Cache Stampede protection for when in a multiple nodes scenario.

To do that a "memory locker" is not enough anymore, since the scope of that is only local.

Solution

I'm also introducing a new IFusionCacheDistributedLocker on top of the existing IFusionCacheMemoryLocker:

public interface IFusionCacheDistributedLocker
  : IDisposable
{
  ValueTask<object?> AcquireLockAsync(string cacheName, string cacheInstanceId, string operationId, string lockName, TimeSpan timeout, ILogger? logger, CancellationToken token);
  object? AcquireLock(string cacheName, string cacheInstanceId, string operationId, string lockName, TimeSpan timeout, ILogger? logger, CancellationToken token);
  ValueTask ReleaseLockAsync(string cacheName, string cacheInstanceId, string operationId, string lockName, object? lockObj, ILogger? logger, CancellationToken token);
  void ReleaseLock(string cacheName, string cacheInstanceId, string operationId, string lockName, object? lockObj, ILogger? logger, CancellationToken token);
}

FusionCache will be updated to allow setting up a distributed locker, similarly to what today is possible with the distributed cache and the backplane.

The fluent builder will also be update to allow specifying one during setup, so that it will be possible to do this:

services.AddFusionCache()
  .WithSerialier(...)
  .WithDistributedCache(...)
  .WithBackplane(...)
  .WithDistributedLocker(...);

As for the Backplane, I'm creating a couple of implementation that will be offered by default:

• an in-memory implementation (usually for testing)
• a Redis implementation (common for production use)
• a null implementation (also potentially usable for testing, like all the other null impls already available)

I'll also add the distributed locker as a new step in the massive Step By Step, so even more coffee will be needed 😅.

[jodydonetti]

I just released v2.5.0 🥳