Backport the split client conn modules

[seanmonstar]

In 1.0, we've split hyper::client::conn::Connection into per-version types. To ease upgrading (see #3052), we can backport the addition of the two modules, hyper::client::conn::{http1, http2}. With them in place, we could then add a deprecation to hyper::client::conn::Connection.

I don't think this will be actually be E-medium in complexity, as it's not adding something that needs many internal changes. But it's not quite easy, since once the files are copied, there might be some confusing errors over internal types that have been renamed.

[kxt]

I've started looking at this, and I'm not quite sure how to go ahead with this backport: the two versions of the conn module both publicly reexport the Body trait from http_body crate, but the 0.14.x code depends on http_body-0.4.5 and the master code depends on http_body-1.0.0-rc1, which is not backwards compatible.

The only way I can see right now is to have both versions of http_body as a dependency, with http_body-1.0.0-rc1 renamed as http_body_backport. Is this something we want to do?

[seanmonstar]

the two versions of the conn module both publicly reexport the Body trait from http_body crate

Do you mean that the bounds for Connection depend on Body? That's fine. I think what I meant in this ticket is not that the new split modules should use a different version of http_body but that the code should look the same as rc1, while using the same dependencies as 0.14.x.

That way, people can prepare to upgrade by making use of hyper::client::conn::http1::Connection (etc), even in 0.14.x, and then upgrading to 1.0 just requires them to change the versions in their Cargo.toml. Does that make sense?

[kxt]

Yes, thank you for your quick reply!

I'm preparing a POC PR. One thing of note is that I've removed the timer method of hyper::client::conn::http2::Builder. As far as I can tell this is a 1.0 feature, so no existing code relies on it.

I've created some smoke tests for the backported API, but I'm not quite familiar with the tests in hyper, I'm open for suggestions of further tests.

[kxt]

On a second thought, I might have gotten overly eager with the deprecation in this PR, that patch might be better off in another issue that tackles the deprecations relevant to the 1.0 upgrade in a systematic way.

[seanmonstar]

At the very least, before landing anything into the 0.14.x branch (which I prefer to be always-shippable, in case of needing speedy fixes), should probably come up with the mechanism to opt-in to the backports (as mentioned in #3052): we don't want to make people compile more code than they are using.

(I don't mean making the deprecations opt-in, those probably should be on to nudge people to start preparing for an upgrade.)

[kxt]

I settled for 1_0-backports for the feature name, as . is not allowed in feature names.

[seanmonstar]

Completed in #3155. (Deprecation was in #3156.)