Upgrade quinn to 0.9.0 for h3-quinn

[inflation]

With the new release of quinn, the APIs are more unified towards a future-based interface. #55 would be a non-issue since the new release has an async write function directly.

Note that all futures returned by quinn are requiring a lifetime now, storing them may not be an option.

[eagr]

Mind if I take this?

[inflation]

@eagr Go ahead

[seanmonstar]

I recently came to this realization of how we can wrap async fns in poll functions. The benefit of them being poll functions in h3 is that we can "wait" for many different events at the same time. async fns tend to take a "lock" on the object, especially if it is &mut self. But since quinn's types can be cloned, it's possible to do an async move dance.

An example is tokio_util::sync::PollSender.

In short, you have an Option field holding the quinn struct, and a tokio_util::syn::ReusableBoxFuture holding the future. The future moves the struct in, and back out:

let rx = self.rx.take().unwrap();
self.recv_stream_fut.set(async move {
    let stream = rx.recv_stream().await;
    (rx, stream)
});

Once you've polled that future, and gotten the quinn struct and the stream back, you put the struct back into the option, and tada. you have a poll fn.

The h3-quinn crate could have this pattern, in order to implement the poll_* functions on the trait. h3 would not need to know anything about it.

[Ralith]

Passing ownership into an aysnc block like that is the approach we recommend, yeah; e.g. the libp2p folks have had some success with it. Other Quinn users have used e.g. futures::stream::unfold to construct 'static futures::Streams, which saves repeatedly moving the struct in/out.