hyper-util: add (tokio) Server struct and builder (inspired by Hyper 0.14)

[GlenDC]

Is your feature request related to a problem? Please describe.

Add a Server to the runtime functionality of https://github.com/hyperium/hyper-util.
For now I would only add one for Tokio, and thus perhaps best kept somewhere in that realm?

Goal would be to add something similar to the server of hyper 0.14. This would allow other libraries like Tonic, Axum and other high level libraries to use it instead of having to define their own very similar logic. For projects like my own (rama) I do not need it.

Describe the solution you'd like

A ready to use Server struct and builder in hyper-util crate for the tokio runtime.

Describe alternatives you've considered

Axum provides in their master version (unreleased) an axum::serve function which does that, but seems a bit silly that for high level crates like axum each need to provide their own? In tower-async (a fork of Tower) I also for now need to each time start my own loop and (tcp) listener, which is a bit silly for such high level examples. Again we can all keep writing our own hyper server, and for some purposes that is desired (like in Rama). But for most users the default Server is probably fine. Even if just to begin with.

[seanmonstar]

I'd be happy for there to be some utilities added to hyper-util, before I mention what exactly those should look like, I want to point out some of the problems of the 0.14 Server:

• Expecting that an Accept could function just like a Stream/AsyncIterator of connections was fine for TCP, but had problems with TLS. Any accepted TCP stream that was then slow on the TLS handshake would then hold up any other TCP streams that were in the queue.
• So for TLS, you'd want to spawn the new task before awaiting the TLS handshake, which means the hyper HTTP builder and MakeService would need to be cloned and moved into the new task too, whereas for just TCP, only the serve_connection needed to be spawned.
• So it kinda feels like Accept couldn't be a stream of established connections, but more like a stream of futures of connections.

[GlenDC]

I think returning a stream of futures makes sense to me.
Myself I spawn these indeed, but that's not a choice we can make for the user,
so having them as futures would allow people to spawn, while it would allow
others to still await them.

So how do you see it? As I was essentially gonna base my initial draft upon the 0.14 server, with some changes that I probably notice while implementing it. So might be useful to already get some feedback here on how you would do it if not that.

[GlenDC]

As I would like to start on this @seanmonstar
can you let me know what you mean with:

I'd be happy for there to be some utilities added to hyper-util, before I mention what exactly those should look like

[seanmonstar]

Ah, I wrote up what I did to let others think about the problem and offer potential solutions. But here's some that come to my mind:

• One of them is described in Make a GracefulShutdown helper in hyper-util #2862. I think that could be useful in general, for anyone just wanting to create their own accept loop.
• I'm fine with someone exploring a new Accept that solves the problems I outlined. I imagine a Server that depends on it could use the GracefulShutdown helper internally.

[GlenDC]

Ok in that case i'll first look into solving #2862 and I'll come back to this one after that.