Proposed addition of --key-slots argument for pre-sharding.

[giantg]

In an attempt to migrate an existing single instance Redis (Community) server to a 3x3 cluster (3 daemons per vm x 3 vms with 2 replicas each) there didn't seem to be any tools or path to restore the existing keys distributed correctly across the cluster.

Unfortunately, the redis-cli --pipe argument does not handle MOVED responses and thus generates errors when the key attempting to be loaded does not fall within the key slot (CRC16 % 16,384) served by the currently connected master node instance.

This is an open issue on the official Redis github here: redis/redis#6098

This new --key-slots argument allows the ability to pre-shard each .protocol file allowing for manually loading to the appropriate master node. In the example above 3 masters serve the following key slots:

16384 / 3 = 5,461

master 1: 0-5460
master 2: 5461-10922
master 3: 10923-16383

So using the new --key-slots argument 3 individual .protocol files can be generated for individually loading the existing keys (from the single instance) to each of the cluster's 3 master nodes:

rdb --command protocol --key-slots 0 5460 dump.rdb -f dump-shard1.protocol
rdb --command protocol --key-slots 5461 10922 dump.rdb -f dump-shard2.protocol
rdb --command protocol --key-slots 10923 16383 dump.rdb -f dump-shard3.protocol

Then the dump-shard#.protocol files can be individually loaded to the node masters of the cluster (with the redis-cli --pipe argument):

redis-cli -h redis-prod1.domain.tld --pipe < dump-shard1.protocol
	All data transferred. Waiting for the last reply...
	Last reply received from server.
	errors: 0, replies: 123

redis-cli -h redis-prod2.domain.tld --pipe < dump-shard2.protocol
	All data transferred. Waiting for the last reply...
	Last reply received from server.
	errors: 0, replies: 456

redis-cli -h redis-prod3.domain.tld --pipe < dump-shard3.protocol
	All data transferred. Waiting for the last reply...
	Last reply received from server.
	errors: 0, replies: 789

I'm sure I have probably not written this addition 100% in line with the current code design. However, I wanted to put this
idea out to see if there would be any interest. I also realize that this code base has grown a bit old at this point and doesn't
support the more current version RDB files (I lucked out in my case being against an older Redis 5.0.14 RDB dump file).