Setting client lib name properly by wrapping multiplxer creation

[atakavci]

Closes/Fixes #406

Current implementation for setting client lib info on connections is only working for single initial connection in the application context/runtime, which leaves the cases and setups given below out of scope;

• client reconnects
• pubsub subscription connections in RESP2 mode
• cluster setup

There are couple of ways to improve the situation with setting library info on connections but all have its downsides. Here some of them with their own drawbacks;

• using connections events
  • this doesnt provide a way to set subscription connections
  • need to manage event registration process for each and every connections explicitly, which is kind of unnecessary burden both in terms of performance and maintenance
• renaming/overriding internals with unnatural/unreliable ways
  • this is risky to play with internals of other library
  • this means introducing a sophisticated code/solution for a simple problem, which would make it
  • this is a potential maintenance issue due to relying on unexposed API/parts of StackExchange.Redis assembly.
• providing a high-level client initializer wrapping both database and multiplexer instances
  • this changes the initial point of contact of developer with the library API and change how the developer experiences
  • it brings maintenance work when the underlying API changes with IDatabase interface, this was handled in a zero-effort manner with help of extension methods previously

I choose to follow the third approach since it is clear, reliable and simplistic implementation compared to other two.
In this PR there are three major types introduced, two of them is exposed in public API;
IRedisDatabase : An interface to allow access to modules commands in addition to those in IDatabase
RedisClient : Provides creation+configuration of IRedisDatabase instances
DatabaseWrapper : Underlying wrapper class to compose IDatabase and modules commands into same type.

Existing implementation with extension methods will stay (at least until a major release) and we will keep these new types as experimental, until we make sure this approach brings more benefits, allow required modifications with underlying types and complies with up-coming changes with StackExchange.Redis.

[atakavci]

hey @slorello89 @uglide
let me know your thoughts on this.

[slorello89]

Couple minor nits, overall LGTM 👍 - will need to update docs to reflect it as well.

[slorello89]

This should be lifted out into an interface IRedisClient and should take an IConnectionMultiplexer in all the places.

[slorello89]

Link back to docs

[slorello89]

I'm assuming the idea here is that if we have a different opinion of how a command should be handled than StackExchange.Redis we can override it here without asking them to break?

[atakavci]

My main motivation here is more on keeping all commands accessible from same object/reference and keep the usage exact same compared to how it is provided with extension methods.

in the future, this might prove useful in the way you pointed out. However, I don't think we'd be inclined to interfere with how SE.Redis handles it.

[atakavci]

from same object/reference

from single object/reference