Add cluster scan implementation

[estepnv]

Fixes #1045

[estepnv]

please suggest what additional tests should I add

[supercaracal]

redis/redis#1962 (comment)

Redis server maintainer said:

I don't think that --scan and --cluster modes play nicely together.

I don't know that how much the feature is needed.
But current redis gem's behavior is a bug indeed. Randomly assign is nonsense.

https://github.com/RedisLabs/redis-cluster-proxy#commands-that-act-differently-from-standard-redis-commands-or-that-have-special-behavior

SCAN: performs the scan on all the master nodes of the cluster.
The cursor contained in the reply will have a special four-digits suffix indicating the index of the node that has to be scanned.
Note: sometimes the cursor could be something like "00001", so you mustn't convert it to an integer when your client has to use it to perform the next scan.

The above proxy feature supports SCAN command by similar interface.
But it seems that the implementation is more simply.

https://github.com/RedisLabs/redis-cluster-proxy/blob/ac83840d1108901a475e24232b7a0986e97e65dd/src/proxy.c#L812-L819

Scan all master nodes in the cluster.
Node order is alphabeticallty and it's taken from clusterGetMasterNames.
The index of the node is taken from the cursor last 4 digits.
If the index is beyond the list of all the master the choosen node will be the last one.
If the cursor is '0', the choosen node will be the first one.
This special cursor format will be handled by handleScanReply, that will append the index of the node to scan to the cursor replied from the cluster.
The real cursor sent to the cluster won't actually contain the index suffix.

https://redis.io/commands/scan
Also, It seems that redis server has just a state as a cursor.

Is it better if we implement it by stateless logic?

[supercaracal]

I am just a contributor. It is eventually needed to review by maintainer.

[supercaracal]

approach 1

• Client raises an error when calling public #scan method in cluster mode.
• Only public #scan_each method is legitimate when using cluster mode.
• It needs conditional branching in public #scan_each method.
• Client internally iterates with double loop by nodes and cursors.
• It might be a breaking changes even if the purpose is a bug fixing.

approach 2

• Client knows ordered nodes.
  • ex) 127.0.0.1:7000, 127.0.0.1:7001, ...
• At first, we can call public #scan method with 0.
• Client returns next cursor and scanned keys. The cursor includes current node index.
  • such that {cursor}-{node index}
  • ex) 17-0, 0-1, 42-1, 0-2, ...
• We can iterate every nodes using only cursor value.
  • Client returns next node cursor when current node iteration is finished.
  • Client returns 0 when all iterations are finished.

I'd say that the approach 2 may be ideal.

[supercaracal]

👍

[byroot]

Please squash your commits together and I'll merge.

[estepnv]

@byroot what about zscan/hscan/sscan, will it work? maybe I should add more tests? I'm not very familiar with internals.

[byroot]

More tests wouldn't hurt.