feat(client): backport split client conn modules

[kxt]

Backport client::conn split modules to ease transition to the 1.0 API and deprecate client::conn::Builder and client::conn::handshake.

Closes #3053

[seanmonstar]

Thanks for getting started on this! I'll try to give CI a kick frequently, looks like it needs a cargo fmt run, and perhaps allow the warning for the C API? Looks like compile errors, actually...

[seanmonstar]

I'm trying to get Miri fixed, but looks like there is a legit failure reported, that the unit tests are using the deprecated API (as they should, we shouldn't remove tests), and that triggers the deny(warnings). Could fix that either with a #![allow(deprecated)] at the top of the file, though that means we won't notice any other crates deprecations, or local #[allow(deprecated)] attributes at each usage location.

[kxt]

Sorry about the previously failing CI tests, I'm not familiar with GH workflows and it took a while for me to set them up working.
The CI tests ran green bar the Miri tests, I don't know what's up with those.

[seanmonstar]

Sorry to delay a little, I wanted to check on something. We've had some useful discussion about deprecations in #3052. It seems worth it to put all deprecation warnings behind a deprecated cargo feature, that we will have off by default to start, and eventually add to the default-features.

Do you want to add that to this PR? If it's too much to do, I can also do it, just let me know :D

[kxt]

I can add it in the next few days. However, the deprecated feature sound odd to me, a feature that causes compile errors/warnings without offering a viable alternative. Having the deprecation behind the 1_0-backports feature would make more sense to me. But I haven't read the mentioned clap issue yet, so there might be a good reason to the deprecated feature that I'm missing.

Also, I guess making the deprecated warnings default should be done with a minor version bump (ie. 0.15) per semantic versioning.

[kxt]

I've added the feature deprecated and renamed 1_0-backports to backports to be in line with #3102. #3052 should be updated with this terminology.

[howardjohn]

I'd be interesting with helper out here if there is any work needed

[kxt]

I also wonder if I can do anything to move this forward.

[seanmonstar]

Sorry, there were a couple of new breaking changes that I realized needed to be made to 1.0. We've made them now. It'd be helpful to users to make sure the "backport helpers" match what ends up in 1.0, so we needed to make them first. For instance, in this PR, the builders no longer have their methods prefixed with the HTTP version (so, not http1_writev(), etc).

[kxt]

Then I guess this PR should be dropped and the issue postponed until it's clear what needs to be backported.

[seanmonstar]

Alright, thanks so much @kxt for doing all this. Sorry for the delay, I've taken your commit and amended it with the latest changes in 1.0, and split it into 2, so we could have backports and deprecations be separate. That's in #3155 and #3156.