Add a CacheNames property to IFusionCacheProvider

[0xced]

Note: this pull request has been opened as draft mainly to discuss the matter since adding an interface member is a breaking change.

I have a scenario in my mind where I'd like to be able to configure the DefaultEntryOptions after the caches are created. I can keep track of all the cache names in a separate collection but I think it would be a good idea to consider this for version 2.0 since the IFusionCacheProvider is the natural place to get all the configured cache names. And I can't inject IEnumerable<LazyNamedCache> to retrieve all the names since LazyNamedCache is an internal type.

Also, the implementation is not very efficient but it was written so in order to minimize conflicts with #249. And after #249 is merged the implementation would become public IReadOnlyCollection<string> CacheNames => _caches.Keys;

[0xced]

I just found about #238 which is very closely related.

It turns out that with the new AsKeyedService method in the upcoming version 1.2.0 and @dotnetjunkie's extension that allows to resolve keyed services as dictionaries it's possible to get all the registered fusion caches and their names.

So maybe this new CacheNames property is not needed after all. Happy to hear your opinion about it though.

[jodydonetti]

So maybe this new CacheNames property is not needed after all. Happy to hear your opinion about it though.

Hi @0xced , do you still need this? I'd like to avoid creating a breaking change, and since you are the only one with this need and there seems to be an alternative like you mentioned, maybe this is not needed anymore.

Let me know.

ps: in any case, the next time I'll make a breaking change I'll definitely consider adding this.

[0xced]

I don't need this actually since I'm happy with the keyed service integration.

The keyed services are still lacking the possibility to retrieve all keys associated with a service type but it's not FusionCache job to fill this gap. There are ways around it but it should definitely be handled by the DI framework itself, see dotnet/runtime#91466.