Async timeout support

[Luminoth]

This adds some basic timeout support to MultiplexedConnection and ConnectionManager (#395) by wrapping the req_packed_command() and req_packed_commands() contents in a tokio timeout when a timeout is set. I've also added a simple example that can be used to induce a timeout with some special treatment of the redis server - SIGTSTP / Ctrl+Z it so that it accepts connections but never responds to commands. This should help with scenarios where an async redis connection stops responding but isn't broken.

[Marwes]

You can just wrap your queries with this timeout instead of putting it in redis itself. I don't see any reason to put this into redis.

[Luminoth]

That means anyone who ever works on our code has to know they need to wrap every call they might add with a timeout (and really any users of the lib should be doing so because it will never return on its own without it if the server doesn't respond to a command). It's a lot safer to have it done consistently at a lower level, imo. I don't think it's uncommon for redis libraries to handle timeouts. Hiredis has redisAsyncSetTimeout() for example.

[Marwes]

For synchronous io you are more or less forced to use timeouts at the lower level and in other languages there has often been a lack of support for cancellation which also forces the timeouts lower. However in Rust, cancellation can just be a future being dropped so there is no actual need to for the timeout (cancellation) to be at this lower level.

Instead the timeout can be fully opt-in, can be put closer to the place that actually cares about being blocked (allowing for multiple operations to be within the same timeout, for instance) and allows for different redis queries to have different timeouts (some queries are fast, others are slow).

[Luminoth]

Sure and that all totally makes sense and I would never advocate for forcing everyone into using a timeout for those same reasons (the change I've done here leaves it as opt-in), but to have no option other than wrapping potentially large numbers of existing calls and an unknowable number of calls that could be added in the future, potentially across multiple applications, isn't entirely ideal I think.

In any case, the change is there if it seems useful at some point to others. As you mentioned the higher level solution is there.