Deduplicate tokio/futures-io implementation?

[NobodyXu]

(Continuation of #377)

The futures-io traits and tokio traits are almost identical except for different name for some methods.

And yet we have two separate impl with lots of duplicate code, having to maintain two implementations adds more burden.

It makes more sense to have a futures-io impl, possibly in a separate crate since futures-io is much faster to compile than tokio, and then simply have the tokio impl wraps its io traits in futures-io to use it.

[NobodyXu]

Turns out that AsyncRead is indeed bit different between them, with tokio using a ReadBuf to support uninitialised buffer

Sometimes I just wish tokio-io is in a separate crate so that we don't have to pull in entire tokio

So if we want to continue this refactor, probably better to have our own io-trait :sad-panda:

[robjtede]

I don't personally think it's worth the churn. Tokio isn't actually a big crate to pull in when the features are set correctly like we do

[NobodyXu]

Yeah I'm not that worried about compile time, but more about duplicate code, was thinking to have the implementation on one set of io-traits and simply bridge them to other io-traits

[NobodyXu]

I just found out that we don't actually support uninitialised buffer, so we force tokio to initialise the whole buffer...that's a so unfortunate

[NobodyXu]

some reminder to myself:

• further deduplicate the code within each generic implementation and its macro to reduce duplicate
• use EncoderV2/DecoderV2