Redis cluster improvements

[Ladicek]

Several commits, best reviewed in isolation:

• show all errors when connecting to Redis cluster fails
• use a subclass of ConnectException on connection failure in cluster/replication client
• fix caching of hash slot assignment in cluster client
• improve some code comments slightly
• treat sharded pub/sub commands as pub/sub commands
• improve how documentation links are generated in RedisAPI

[Ladicek]

My main motivation for this are:

• Redis cache: Failed to connect to all nodes of the cluster quarkusio/quarkus#37041
• Redis cluster doesn't reconnect when node returns online quarkusio/quarkus#37348

[sfali16]

Code changes look good.

Some comments (1 and 2 are stylistic, and 3 might affect retries for non-cluster client connections):

1. Should the commit comment explaining the use of a class dervied from ConnectException be in the javadocs of one of the connect methods or the RedisClusterClient itself?
2. Should we encapsulate this logic of using a RedisConnectException in its own function to better clarify the logic, and for future editors to reuse to do the right thing?

onGotSlots.handle(Future.failedFuture(new RedisConnectException("Cannot connect to any of the provided endpoints")));
to

onGotSlots.handle( failWithRetryableException( "Cannot connect to any of the provided endpoints"); 
// .. some other code 
/**
 * Return future that resolves with a RedisConnectException, an instance of ConnectException that will signal to clients that they can retry the connection
 */
public Future<RedisConnectException> failWithRetryableException( message ) { 
    return Future.failedFuture( new RedisConnectException( message ));
}

3. Finally should the same logic to wrap failures in a RedisConnectException apply to the RedisBaseClient ? You may have a good reason for this - but why is it only applicable to the cluster or replication clients?

[Ladicek]

I could add something like RedisConnectException.failedFuture(String) and add a comment on that method. That's a good point.

It is required to use a ConnectException explicitly for the cluster and replication clients, because they fail the connecting process using a custom logic. The other clients propagate the original underlying exceptions directly, so they should be fine (I tested with the standalone client, but didn't bother checking with sentinel).

[Ladicek]

I didn't do RedisConnectException.failedFuture, but I added a comment directly on RedisConnectException.

[vietj]

LGTM good work