Recognize byte slice for key argument in cluster client hash slot computation

[LINKIWI]

This PR is mildly related to #3048.

The cluster client uses the command type to determine the expected key position in the command arguments slice to compute the hash slot. This enables the client to properly send the command to the node that owns that slot, according to the cached cluster topology state.

For generic commands assembled with the Do() API, the logic falls back to assuming the key is at position 1. Though this is a reasonable assumption, it depends on the argument to be of string type; []byte type arguments are not converted to strings, which results in an incorrect slot computation, thus forcing (in most cases) a double round trip caused by response to a MOVED redirection.

This PR adds a []byte type case for key string serialization, so that the generic commands passed as byte slices yield the correct cluster hash slot.

[monkey92t]

It seems that you have restricted modifications to your PR code. You can either open the permissions or resolve the conflicts yourself.

[LINKIWI]

It seems that you have restricted modifications to your PR code. You can either open the permissions or resolve the conflicts yourself.

Done! Rebased and conflicts resolved

[monkey92t]

@ofekshenawa merge?

[LINKIWI]

Is it possible to merge this? This PR fixes a pretty significant performance bug for us. Thanks!

cc @vladvildanov @ofekshenawa

[LINKIWI]

@ofekshenawa I rebased this branch and the build is now green. Are we good to merge? Thanks.

[LINKIWI]

@vladvildanov @ofekshenawa Are you able to help with this merge? We have been running this patch in production for several months and have confirmed that it fixes the issue in the PR description.

[ofekshenawa]

@LINKIWI Sorry for the delay, approved and merged!