RediSearch - override cluster behavior

[a-TODO-rov]

See #3447

[uglide]

@tishun let me know if you agree on the API change I suggest

[uglide]

LGTM

[tishun]

So I think that if we

• (optional) add the commands to the ReadOnlyCommands
• (required) and we also make sure the right commands are made keyless
  ... we would have the basis to implement the command tips / request-response policies

Why:

• in the RedisAdvancedCluster* we will override the logic to what we want the driver to do
• we would have the right API, which is extremely important (no commands that are keyless would be marked like having keys)
• the right commands would be read-only commands

With a new change we can then do the necessary changes and extract the logic from the RedisAdvancedCluster* elsewhere (and in a single place).

[tishun]

Can we make this method with package visibility and add JavaDoc explaining what it does?

[a-TODO-rov]

done
there is a new method now - one that accounts user ReadFrom preferences
check:
6d8dad4

[a-TODO-rov]

So I think that if we

• (optional) add the commands to the ReadOnlyCommands
• (required) and we also make sure the right commands are made keyless
  ... we would have the basis to implement the command tips / request-response policies

Why:

• in the RedisAdvancedCluster* we will override the logic to what we want the driver to do
• we would have the right API, which is extremely important (no commands that are keyless would be marked like having keys)
• the right commands would be read-only commands

With a new change we can then do the necessary changes and extract the logic from the RedisAdvancedCluster* elsewhere (and in a single place).

1. I added the read-only RediSearch commands to the default values of ReadOnlyCommands. So now if the user prefers to ReadFrom.REPLICA, those commands will be routed to REPLICAS. This is possible after this commit
2. Although i agree that changing the API and making the keyless commands truly keyless is nice to have, i can't agree that this is required in the scope of the current PR.
   Why:

• Has no impact on the current solution - weather we make those changes or not, nothing will change in the way the solution works in this PR. As i understand its more like a technical debt cleanup and preparation for the future (that is unknown)
• Separation of concerns - i don't like to "pollute" a ready, tested and working solution with unnecessary(for the current scope) changes, that can bring their own bugs.
• This is supposed to be a step in implementing a more general, centralized solution, but i am not sure in that statement - not until some kind of architecture is drafted and agreed on.

However, from my perspective, those changes will have impact over how the users perceive the API (currently when commands have key, the user expects slotHash routing in cluster). Thats why i will be happy to introduce those changes, but as a part of different PR, if you and @uglide agree.

[a-TODO-rov]

You can check the API changes for keyless search commands in #3456