consolidate http client implementation(s) (#3866)

## Motivation and Context
<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here -->

* #3710
* #1925
* awslabs/aws-sdk-rust#977

## Description
This is the first of what I'm going to assume will be several PRs on the
path to migrating us to hyper 1.x. The goal is to reach a desired state
as far as crate organization, feature flags, and how this is all enabled
by default (eventually). This first PR just moves existing HTTP client
support around as prep work for what's to come.

NOTE: This is all getting merged into a staging branch `hyper1` rather
than `main`

* Migrate `hyper-0.14` and `hyper-1.x` support into a new
`aws-smithy-http-client` crate.
    * re-export `hyper 0.14` from `aws-smithy-runtime`. 
* Remove support from `aws-smithy-experimental` for hyper 1.x and leave
breadcrumb for where it lives now.
* Migrate `CaptureSmithyConnection` into `aws-smithy-runtime-api` so
that it can be used by new crate without creating a circular dependency.


Why a new crate? 

Several reasons:
* The entire hyper and rustls ecosystem bifurcates on hyper 0.x. The
resulting `Cargo.toml` is kind of a mess as a result. In a new crate we
can isolate this ugliness as well as manage feature flags more
meaningfully with this in mind.
* Placing the HTTP client implementation in `aws-smithy-runtime` makes
it a load bearing crate for all of the HTTP and TLS related feature
flags we may wish to expose _in addition to it's own feature flags_.
This sort of explodes with the aforementioned bifurcation.
* I expect `aws-smithy-runtime` and generated SDKs to choose a default
configuration but customers can pull in this new
`aws-smithy-http-client` crate and enable different flags for specific
use cases (e.g. FIPS).
* A new crate may be a good place to explore new functionality (e.g.
we've considered forking our own implementation of `hyper-util` legacy
client, this gives us a natural place for that should we go down that
route)

## Future

Where are we going?

* I want to relocate all of
`aws-smithy-runtime/src/client/http/test_util` into the
`aws-smithy-http-client` crate. These are utilities for testing with a
mock/fake HTTP client and they make more sense in this new crate. This
also allows us to update the utils to support the hyper/http 1.x
ecosystem and feature gate the legacy ecosystem. We can re-export the
legacy ecosystem test support from `aws-smithy-runtime` for now.
* Update our internal usage of these test utils with the new 1.x
ecosystem and deprecate the old APIs but leave them in place.
* I expect we'll deprecate them with a plan to remove or at least
feature gate differently in the future with a recommendation to upgrade.
* I want to explore the tickets/use cases people have asked for to see
what/if we can do anything better with the hyper 1.x API surface. In
particular I think we may want to just expose our own builder type (new
type around hyper-util builder).
* Because `hyper-util` is not 1.x we can't expose the
`HyperClientBuilder` like we did previously. I don't think we should
even if it was 1.x though, we should offer a "default client" with knobs
for all the things we do want to support directly. Anything not found
there you have to bring your own client configured to your heart's
content.
* We need to explore if we can make `aws-lc` the default (at least on
`unix`).
* I want to add optional support for `s2n-tls` to
`aws-smithy-http-client` and reconcile related crypto/tls feature flags
with this in mind.
* Need to figure out how we set the default for `aws-smithy-runtime` and
generated clients to be hyper 1.x and add appropriate new flags, etc.
* Update changelogs, versions, lockfiles, etc.

----

_By submitting this pull request, I confirm that you can use, modify,
copy, and redistribute this contribution, under the terms of your
choice._

.cargo-deny-config.toml

@@ -4,10 +4,6 @@
 # More documentation for the licenses section can be found here:
 # https://embarkstudios.github.io/cargo-deny/checks/licenses/cfg.html
 [licenses]
-default = "deny"
-unlicensed = "deny"
-copyleft = "deny"
-allow-osi-fsf-free = "neither"
 allow = [
     # See https://spdx.org/licenses/ for list of possible licenses
     # [possible values: any SPDX 3.11 short identifier (+ optional exception)].
@@ -19,6 +15,7 @@ allow = [
     "MPL-2.0",
     "Unicode-DFS-2016",
     "Unicode-3.0",
+    "Zlib"
 ]
 confidence-threshold = 1.0
 exceptions = [

.github/workflows/ci.yml

@@ -236,35 +236,35 @@ jobs:
     name: Exotic platform support
     runs-on: ubuntu-latest
     timeout-minutes: 10
+    env:
+      CROSS_CONFIG: Cross.toml
     strategy:
       fail-fast: false
+      # We always exclude `aws-smithy-http-server-python`, `aws-smithy-http-server-typescript`, and `aws-smithy-experimental` since they are experimental.
+      # We exclude `aws-smithy-http-client` due to FIPS related feature flags and aws-lc-fips target support
       matrix:
         include:
-        # We always exclude `aws-smithy-http-server-python` and
-        # `aws-smithy-http-server-typescript` since they are experimental.
         - target: i686-unknown-linux-gnu
           build_smithy_rs_features: --all-features
           build_aws_exclude: ''
-          build_smithy_rs_exclude: --exclude aws-smithy-http-server-python --exclude aws-smithy-http-server-typescript --exclude aws-smithy-experimental
+          build_smithy_rs_exclude: --exclude aws-smithy-http-server-python --exclude aws-smithy-http-server-typescript --exclude aws-smithy-experimental --exclude aws-smithy-http-client
           test_smithy_rs_features: --all-features
           test_aws_exclude: ''
-          test_smithy_rs_exclude: --exclude aws-smithy-http-server-python --exclude aws-smithy-http-server-typescript --exclude aws-smithy-experimental
+          test_smithy_rs_exclude: --exclude aws-smithy-http-server-python --exclude aws-smithy-http-server-typescript --exclude aws-smithy-experimental --exclude aws-smithy-http-client
         - target: powerpc-unknown-linux-gnu
           build_smithy_rs_features: ''
           build_aws_exclude: --exclude aws-inlineable
-          build_smithy_rs_exclude: --exclude aws-smithy-http-server-python --exclude aws-smithy-http-server-typescript --exclude aws-smithy-experimental
+          build_smithy_rs_exclude: --exclude aws-smithy-http-server-python --exclude aws-smithy-http-server-typescript --exclude aws-smithy-experimental --exclude aws-smithy-http-client
           test_smithy_rs_features: ''
           test_aws_exclude: --exclude aws-inlineable
-          test_smithy_rs_exclude: --exclude aws-smithy-http-server-python --exclude aws-smithy-http-server-typescript
+          test_smithy_rs_exclude: --exclude aws-smithy-http-server-python --exclude aws-smithy-http-server-typescript --exclude aws-smithy-experimental --exclude aws-smithy-http-client
         - target: powerpc64-unknown-linux-gnu
           build_smithy_rs_features: ''
           build_aws_exclude: --exclude aws-inlineable
-          build_smithy_rs_exclude: --exclude aws-smithy-http-server-python --exclude aws-smithy-http-server-typescript --exclude aws-smithy-experimental
+          build_smithy_rs_exclude: --exclude aws-smithy-http-server-python --exclude aws-smithy-http-server-typescript --exclude aws-smithy-experimental --exclude aws-smithy-http-client
           test_smithy_rs_features: ''
           test_aws_exclude: --exclude aws-inlineable
-          test_smithy_rs_exclude: --exclude aws-smithy-http-server-python --exclude aws-smithy-http-server-typescript --exclude aws-smithy-experimental
-    env:
-      CROSS_CONFIG: Cross.toml
+          test_smithy_rs_exclude: --exclude aws-smithy-http-server-python --exclude aws-smithy-http-server-typescript --exclude aws-smithy-experimental --exclude aws-smithy-http-client
     steps:
     - name: Checkout
       uses: actions/checkout@v4