[NEW] Enable using a connection while waiting for a blocking command

[nihohit]

Blocking commands complicate multiplexing several logical connections over the same physical connection, and in general are a perf hassle. There are 2 existing suggestions for ways to overcome this issue -

redis/redis#12873
redis/redis#12716

either one could allow client writers to safely multiplex several client objects over the same physical connection, and help users get the most out of their machines.

[zuiderkwast]

I like the opt-in for a possible +ASYNC reply to async commands, with the actual reply delivered later using Push. It solves the problem for clients. They can hide this handling from the end user. I have thought about this and I can't find any real problem with it. I would accept a PR.

Multiplexing. It solves more problems than just blocking commands. I don't like the suggested solution in that issue though. Instead we can support RESP over QUIC, with optional linking with a QUIC library, such as MsQuic. QUIC is unusual now, but it will be more common in the future.

[mzimbres]

Can't you avoid blocking commands by using some form of the client-side-caching or key-space notifications?

[nihohit]

@mzimbres can you? for every blocking command?