Split the server Connection type into version-specific submodules

[seanmonstar]

The server::conn type, Connection, should get version-specific types in submodules http1 and http2.

[tomkarw]

Hey @seanmonstar, I think I'd like to work on this next.

However, I need a few additional pointers before I can start:

• Do we want to split only the Connection type, or all/most of the types in the server::conn? Is it just that we want to start simple, as the same argument can be made for the rest of the file?
• There will be some code duplication. Are we okay with that, or should we abstract to some common free functions?
• There are methods that require both http1 and http2 features, like upgrade_h2. Just to sanity check, that would be a method in http1::Connection that would still require both features enabled, take self by value and return http2::Connection.

I'd ask you for clarifications, confirmation that we still want to work on this, and maybe some new thoughts that you had about the topic.

[seanmonstar]

Yes, this is something that still needs to be done.

Do we want to split only the Connection type, or all/most of the types in the server::conn?

Lemme take a look... I think that the types currently in server::conn should be remove from the public API. Connection should exist in both. So should a builder. The Addr* types are gone already. The Connecting should be gone as well, if not already.

Duplication ... should we abstract to some common free functions?

Some duplication is fine. It's also fine to refactor to some free functions in server::conn, as long as they stay private. De-duplication is less urgent than getting the API breaking changes in place, so we can ship the RC.

There are methods that require both http1 and http2 features, like upgrade_h2

Those should likely be removed, to start with. We can add them back in a way that hyper_util::server::AutoConnection could handle either version. (That's part of the goal of #2852, but the urgency is lower).

[Michael-J-Ward]

Those should likely be removed, to start with. We can add them back in a way that hyper_util::server::AutoConnection could handle either version. (That's part of the goal of https://github.com/hyperium/hyper/issues/2852, but the urgency is lower).

Do the connections then become simple-wrappers around the underlying dispatchers?

http2 definitely can be, and if we remove fallback from http1::Conneciton then I believe it can be as well