Refactor legacy client to be independent of tokio

[erickt]

This patch decouples the functionality of client::legacy from tokio, by lifting up a Client, HttpConnection, and Resolver into the client module. For backwards compatibility, it reimplements client::legacy to be based off of the new code.

As best as I can tell it should be backwards compatible, and passes all the tests.

There's a couple of areas where I'm not sure if we got quite the right API:

• Capturing connection info - This adds a helper closure you can call to get it, which is then used by he legacy client to send the info to the tokio watch.
• This extracts the pool info, but there's been a long standing plan to replace it with something better. I'm not sure what that would look like though.
• I set up the legacy Client and HttpConnector to wrap the new generic APIs. That adds a bit of code duplication, but as far as I can tell we can't use a type alias due to the new method.

This is an experiment, so I wouldn't be surprised if it needs changes. To test out the design, I also have a WIP branch to update hyper-rustls to use the new interface, found in https://github.com/erickt/hyper-rustls/tree/new-client. I'll not push that up as a PR for now to avoid splitting the conversation, but I did want to cc @djc since you might also have opinions about how this should look.

Note that I did use AI to help with the refactoring, but I did review the code, and did a lot of the restructuring by hand.

Fixes #3842.

[djc]

The hyper-rustls part of this looks okay to me, though it definitely feels like there should be a shorthand for HttpConnector::new(TokioGaiResolver::new(), TokioSocketConnector::new()) (perhaps it could be spelled HttpConnector::default()?).

[sjcobb2022]

Whilst I do think this can have it's use for backwards compatibility with older codebase, why not just use the new pooling client?

At least: why should a new user decide to use this instead of the pooling client?

[erickt]

@sjcobb2022 - whoops! I didn't notice there was a new pooling client. I'll add support for it.

[sjcobb2022]

The new pooling client is already basically generic over an executor. See #243

[erickt]

@sjcobb2022 - thanks for the reference! From the doctests in #243 it seems like that patch is still dependent on a hyper::client::connect::HttpConnector that doesn't exist yet. Is that being developed elsewhere? If not yet, I could factor out the generic parts of this PR'ssrc/client/connect/http and post it upstream to start the process?

[sjcobb2022]

@sjcobb2022 - thanks for the reference! From the doctests in #243 it seems like that patch is still dependent on a hyper::client::connect::HttpConnector that doesn't exist yet. Is that being developed elsewhere? If not yet, I could factor out the generic parts of this PR'ssrc/client/connect/http and post it upstream to start the process?

No, but any inner transport could use this, e.g. use a raw tcpstream instead of a httpconnector, or a raw tcpstream wrapped in an sslstream from rustls. The HttpConnecter was used in doctests for simplicity