Switch to quinn

[alecmocatta]

The current implementation using the berkley socket API for TCP is a nightmare, primarily due to it being difficult to a) shut down TCP neatly and b) recover from transient "errors" that reset connections.

Fortunately quinn doesn't have these issues and is great to work with.

This will involve one big API change: Sender::new and Receiver::new will be replaced by let (sender, receiver) = channel();, which mirrors futures::channel::mpsc::channel(). Senders and Receivers will be (de)serializable. This will also ensure static type safety 🎉

[harksin]

Hi @alecmocatta, just by curiosity, why quinn and not quiche ?

[alecmocatta]

@harksin quinn integrates with std::future::Future and tokio, whereas quiche necessitates an explicit event loop (probably mio). I value the former paradigm more. I got the sense that quinn is more ambitious and more ambitious in leveraging the Rust language and ecosystem, whereas quiche is more focused on encapsulated C/C++ bindings. Overall I really liked the design and implementation of quinn, whereas quiche didn't excite me as much.