Refactoring

[benashford]

Do some wholesale refactoring to tidy-up loose ends.

Summary

The previous two releases of redis-async-rs had some compromises that needed to be introduced for correctness while maintaining backward compatibility. In particular a Mutex had to be introduced to resolve contention when ascertaining the state of the shared connection that could be written to by multiple tasks, and due to guarantees advertised by the API, it had to be a std::sync::Mutex rather than an async/await compatible Mutex.

Of course this is an anti-pattern which should be avoided as it can cause a multi-threaded runtime to become synchronised in a way that isn't desirable. Fortunately the period of the lock is so short it didn't cause any noticeable practical problems.

However, it still shouldn't exist. So this PR makes the necessary breaking changes to enable a solution that has no Mutex.

In practice this changes the API in a few subtle ways (types of parameters), but clients should be able to upgrade with no significant difficulties.

One breaking change that I won't make as-yet is the guarantee that commands are sent to Redis in the same order as calls to send are made. It requires some internal complexity, and arguably it's not idiomatic, but I'm retaining it as a feature for now because if anything depends on it it may come as an unpleasant surprise if it were to suddenly stop. Basically, calling send isn't an asynchronous operation (and is non-blocking) but it returns a future which is asynchronous in order to read the result.

I will however, stop advertising that guarantee as a feature so that a forthcoming major release might drop that guarantee.

Also...

This enables switching of runtimes with feature flags. Tokio 1.0 is the default, but Tokio 0.2 is also supported. There is also experimental support for Async-Std, but this should be considered unstable at this stage.

Performance

Removing the Mutex with an indirect queue does seem to have a fairly hefty performance penalty (40% or so) for single-threaded situations, but should be better in more complex situations where there would otherwise be contention for the lock.