Implement RedisClient::Cluster#with (again!)

[KJTsanaktsidis]

This PR actually implements the #with method for checking out a connection directly to a particular Redis node. This allows you to perform transactional commands directly against the underlying RedisClient instance, so #watch, #multi, etc all work.

This does NOT yet implement any kind of validation for the commands issued. If you issue commands involving keys not owned by the node, you will receive Redis::CommandError's. A future PR will add client-side validation to hopefully make it possible to catch problems related to transaction misuse earlier in development. There's a pending test for this.

This PR also does not yet implement RedisClient::Cluster#multi in terms of #with. That will also come in a future PR.

[supercaracal]

I'm wondering the naming of slot_key is general for Redis cluster users. Although it may be a bit redundant, would key_for_slot be easier to understand?

[KJTsanaktsidis]

I bounced through a few options with this:

• key: - This sounds nice, and sometimes you really will pass a key here (if you're doing MULTI on a single key). But, you can and normally will pass things which aren't even real keys here - i.e. just the bare hashtag like {foo}.
• slot: - This is what the parameter is for - it calculates the slot based of what you pass in here - but it kind of implies that you actually pass a slot number in here, rather than a key (we could make it work by passing in a slot number too, but i don't see the use case - 99.999% of the time it'll be a hashtag you pass in).
• hashtag: - this parameter would be "foo" instead of "{foo}". It has the right name, but if you're doing single-key operations you might not actually have a hashtag.
• slot_key: - This is where I ended up, it has what it is ("key") and what it's for ("slot") in the name. It's a bit verbose though.
• key_for_slot: - This is probably even more clear but also even more verbose than slot_key.
• Another option is to make it slot:, have it take a number, and also expose a slot_for(key) method, so you'd call it as client.with(slot: client.slot_for(key)) do |conn|. This feels a bit overly complicated though because i can't think of a use-case for actually passsing a slot number in there that didn't come from hashing a key.

I don't mind too much which one we choose - they all have upsides and downsides. Happy for you to pick something off this list and I'll change the implementation to that :)

[KJTsanaktsidis]

OR - how about we do both key: and hashtag:?

• You can pass key:, and we'll hash it and use that slot. This will work for single keys and keys with hashtags in them
• You can pass hashtag:, and we'll raise an exception if it doesn't match {...}. Then, we'll hash it and use that slot like key.

So you can write client.with(hashtag: '{foo}') do |conn| normally, but if you want to do single key operations, you can do client.with(key: 'fookey') do |conn|. It's slightly redundant because technically key can do everything that hashtag does, but using hashtag: makes it much clearer when reading the code that the block will operate on multiple keys with that hashtag.

[supercaracal]

👍 I'd like to upvote your idea.

[KJTsanaktsidis]

@supercaracal This should be good to merge now hopefully! 🤞

[supercaracal]

Thank you!