Proposal: SSubscribe should (could) reuse existing connection to node

[maqdev]

Existing implementation creates a new TCP connection for every SSubscribe which is inefficient if there are multiple channels located on the same node.

Technically there's a workaround at the user side of the Redis go - instead of calling client.SSubscribe, it's possible to reuse a PubSub and call PubSub.SSubscribe for subsequent channels that are hosted (sharded) to the same node but it requires following cluster topology, keeping track of PubSubs and duplicating sharding logic to the caller.

A proposal is to reuse existing connection pool instead for SSubscribe or maybe create a separate pool for SSubscribe but limit number of connections created to a single Redis node.

[ndyakov]

That is good idea @maqdev, there is already a dummy pub sub pool that may help with this. I may not be able to add this to my workload at the moment, but if you would like to take a look at it I can assist with review and guidance.