Support writing Avro containers asynchronously

[alexbiehl]

Currently avro_rs::Writer expects the underlying writer to implement std::io::Write which makes it unsuitable for use in streaming environments with futures/async_std/tokio.

I know the ecosystem is a little scattered but it would be great if avro_rs supported one of the asynchronous write interfaces like tokio::io::AsyncWrite or async_std::io::Write.

[kendru]

Would a PR that adds support for tokio::io::AsyncWrite be desired by this project?

[poros]

Thanks for being willing to contribute, @kendru!

I am not thrilled by the perspective of tying this library to any of the async runtimes, as there isn't truly any standard atm (although tokio seems to be the most mature among them). Even if we want to add support for it, it would be under a cargo feature.

@alexbiehl is also the only one who asked for such a feature, so I can't really tell that there is much of request for it either.

As for now, perhaps we could offer the possibility to the users of implementing the Writer interface, so they can implement it for their runtime of choice? What do you people think?

[kendru]

@poros I completely understand not wanting to tie this library to a specific async runtime, and I would be happy to try implementing tokio's AsyncWrite interface under a cargo feature. This functionality would be very useful for a project that I am currently working on, and I would imagine that as the use of async code in Rust becomes more common, this will be useful for more people. Since tokio does look like the de-facto runtime, I think that it would make sense to support it. That said, if you are still not convinced that it would be useful for this library to offer an async interface, I completely understand.

[poros]

I am only a bit worried that we will need to keep maintaining it in a fast-changing ecosystem when, at the end, it isn't a core component of a serde library.

@kendru : what do you think about the Writer public trait approach I mentioned above? Would that allow you to implement something that works with tokio? If not, I would be OK to go for the cargo feature approach.

[sycured]

Have you any ETA about async?

@kendru have you any fork or patch for async?

How to permit the usage of tokio and async_std?