Make serve generic over the HTTP implementations

[mladedav]

Motivation

Currently, only serving with hyper with predefined configuration is supported out of the box. This runs into issues where people want to configure hyper settings (#3305, #2980, #2939). It's fairly complicated to use anything but the default hyper setup, though it is of course possible even now as shown in several low-level examples.

I see this as the natural extension of #2941. We can allow serve to not only be generic over the way connections are accepted, but also how they're handled before a Request is created for our router to handle (and how to handle the returned Response).

Solution

This adds a ConnectionBuilder trait that receives an Io and Service and connects them to an underlying logic that handles HTTP, e.g. a hyper connection.

The current implementation adds hyper-util as a public dependency which might not be desirable, in which case we may want to not expose the constructor with Builder, and have a 3rd party crate like axum-server create something like this with exposed internals. That would go a bit against the issues listed in motivation, but even with that, I think it would be nicer to expose hyper-specific settings this way as well as letting others to build custom ConnectionBuilders without having to copy the whole serve implementation from here.

I've also added two examples. One is TLS usage with otherwise the default hyper implementation and the other is for showcasing using something else than hyper, in this case Rama.

[jplatte]

That's a big diff (even excluding Cargo.lock). I'll see about finding time to review it. Also the Cargo.lock makes me once again want to split examples into their own repo...