New API proposal: improve support for pinned server ad-hoc commands

[mgravell]

Context: some commands (example: FT.CURSOR READ) in a cluster is only valid when used against the node that issued the command (see redis/NRedisStack#239).

Also: historically it has been kinda awkward to switch to IServer.

Proposal:

1. Add a new API to get a routed IServer from IConnectionMultiplexer:

IServer GetServer([RedisKey key], [CommandFlags flags]) // or GetServerForKey, or GetRoutedServer; naming is hard

semantics:

• if a key is provided on a clustered setup, we return a single-endpoint instance that matches the provided key (and flags, for primary/replica etc)
• otherwise, a single-endpoint instance (matching the flags, for primary/replica etc) is selected arbitrarily

2. Add a database-aware Execute to IServer:

RedisResult Execute(int? database, string command, params object[] args);
RedisResult Execute(int? database, string command, ICollection<object> args, CommandFlags flags = CommandFlags.None)

(and async twins)

semantics:

• database is always enabled in this usage, so null maps to how GetDatabase(-1) works, i.e. "the default as specified on the options" - if you want to issue a non-db command, the existing API already allows that
• parameter order is intentional to avoid ambiguity with the existing API

[NickCraver]

FWIW I think GetServer(RedisKey...) with a description is clear and obvious - the only pause I have is RedisKey implicit conversion to int and if that yields some fun in practice.

What happens on a rebalance?

[mgravell]

I didn't think RedisKey converted to/from int, but I can check tomorrow. In the case of rebalance, I think all bets are off. This is already an atypical routing scenario, so I think all we can do is say "this API uses fixed server routing, whatever happens: happens", aka YOLO.

[mgravell]

Confirmed that RedisKey has no int conversions, so: no ambiguity here. Proposed implementation ^^^.

[NickCraver]

ACK - +1 on proposal, comments added on PR specifics!