Allow a custom IDistributedCache to be resolved

[Erwinvandervalk]

What issue does this PR address?

You're now able to inject a custom instance of IDistributedCache.

This is done by introducing a class called OptionallyKeyedDependency. This makes it explicit that a specific dependency will normally use the default, but this can be overwritten with the key 'duende'.

services.AddKeyedSingleton<IDistributedCache>(OptionallyKeyedDependency.Duende, replacementCache);

The key 'duende' was chosen so all our services can use the same override key.

If you want, it's possible to change this key and thus inject a different IDistributedCache for each service.

// register the cache, but using a different key (not default 'duende')
services.AddKeyedSingleton<IDistributedCache>("different", replacementCache)

    // Now register a custom OptionallyKeyedDependency that uses the different key
    .AddKeyedTransient<OptionallyKeyedDependency<IDistributedCache>,
        CustomOptionallyKeyedDependency<IDistributedCache>>(nameof(DistributedClientCredentialsTokenCache));

Fixes: #50

[josephdecock]

I think the API that we have here is complex and while maybe we need that complexity, I would like to explore alternatives. Did you consider creating marker interfaces instead of keyed dependencies? We could have IDistributedCacheForFoo, which could just derive from IDistributedCache, and then if you want a specific caching behavior in Foo, you just inject what you want for that interface.

[Erwinvandervalk]

I did consider Marker interfaces. They would have been the only way to address this before keyed dependencies where introduced, but I believe this is exactly what keyed dependencies were introduced for.

The reason I chose this particular approach is that we introduce 3 layers of customization:

1. user injects a custom cache, that's used everywhere
2. user injects a custom cache ONLY for duende software (we'd need to implement this pattern in our other libs of course)
3. user injects a custom cache ONLY for a specific use case (IE: token storage)

With a marker interface (or if I would re-write the logic just with some DI magic), you'd either loose option 2 OR option 3.

As for the extra complexity, I think actually this is quite a bit simpler than using a marker interface. With a marker interface, a consumer needs to use an adapter.

If we don't want to use the OptionallyKeyedDependency class, then I could just re-write the logic using some DI-wizardry, but you'd loose option 2 or 3 as well.