Previously, the `RedisClusterClient` used to obtain the hash slot
assignment as the first step of each `connect()` call. This is fairly
expensive and increases the load on the first endpoint in the list
(because we target the first endpoint when issuing `CLUSTER SLOTS`).

It is also unnecessary. Redis always sends a redirection when the node
to which a command is sent is not assigned the hash slot targetted
by the command. Until we observe such redirection, the hash slot
assignment we observed before is still valid. Hence, we can store
the hash slot assignment in the `RedisClusterClient` and reuse it
for all `RedisClusterConnection` objects, until the `MOVED` error
is seen. In such case, we reset the hash slot assignment so that
the next `connect()` call fetches it again.

To avoid spurious failures (it could happen that the cluster is
resharded such that a command that would fail under the existing
hash slot assignment will no longer fail, because the hash slots
that were previously assigned to multiple nodes are now assigned
to a single node), the hash slot assignment is not kept permanently.
Instead, it is treated as a cache with configurable TTL, defaulting
to 1 second.