[DistributedLock.Redis] Bugfix: respect IDatabase key prefix

[skomis-mm]

Fixes an issue with Redis keyspace isolation for locks using WithKeyPrefix extension method on IDatabase:

var database = multiplexer.GetDatabase().WithKeyPrefix("distributed_locks:");
var gate = new RedisDistributedLock("lock1", database);

using (gate.Acquire()) // creates lock with key "distributed_locks:lock1"
{
     // ..
} // bug: does not release the lock since it tries to delete "lock1" key

[madelson]

@skomis-mm thanks for filing this! I'd like to publish a patch release for this. Some steps for doing that:

1. Can you please change the target branch of this PR to point to the new release-2.0.1 branch I created instead of master?
2. See the comment I left about adding a couple of source code comments.
3. I'll want to add test coverage around this. You are welcome to do so but I can also do it if you'd like; just let me know. The cases I want to add are:
   (a) Add a new provider in TestingRedisDatabaseProviders.cs which has a single database using a key prefix, then run the TestSetupTest to add new combinatorial tests based on this provider. This will give assurance that all operations across all the Redis classes are key prefix friendly.
   (b) Add a test to RedisSynchronizationCoreTestCases.cs that does the following: (i) sets the test's databases to just default server 0 with a key prefix P and creates a lock named N. (ii) sets the test's database to just default server 0 and creates a lock named N, (iii) creates a lock named P + N. (iv) demonstrates that locks 1 and 2 do not interact, but 1 and 3 do interact.

[madelson]

Wow this change is super subtle. Is the idea that all other IDatabase methods will add the key prefix too? We do use non-script evaluations in a few places.

[skomis-mm]

Thats right, .WithKeyPrefix(..) returns IDatabase decorator with the key prefix as context data.

[skomis-mm]

will re-branch from 2.0.1