add https proxy support

[aajtodd]

Motivation and Context

awslabs/aws-sdk-rust#169

Description

• Adds support for automatic support for common proxy env vars (HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY and their lowercase versions) behind a new BehaviorVersion
• relocates the TLS providers to their own modules, these are largely the same with the biggest change being wrap_connector returns dedicated connector types for rustls and s2n and the addition of new connect modules containing the proxy tunnel logic for each TLS provider.
  • This results in a bit of repeated logic to handle proxy tunneling but I couldn't find a way to unify the implementations and abstract out just the manual TLS handshake due to type system constraints
• updates dependency versions in aws-smithy-http-client
• added a new build_with_connector_fn that allows creating a SharedHttpClient by passing your own function for creating connectors. We didn't have a way to configure aws_smithy_http_client::Connector and turn it into a SharedHttpClient without going through http_client_fn. That works but it doesn't re-use the same caching logic for connectors as we do when going through aws_smithy_http_client::Builder. The alternative would be to make the client builder in aws-smithy-http-client behavior version aware. Doing it the way it is in the PR allows us to externalize this though and handle it in aws-smithy-runtime when creating the default https client

Testing

• integration tests with mock proxy over localhost
• tested against mitmproxy using different combinations of env variables and behavior versions

Checklist

• For changes to the smithy-rs codegen or runtime crates, I have created a changelog entry Markdown file in the .changelog directory, specifying "client," "server," or both in the applies_to key.
• For changes to the AWS SDK, generated SDK code, or SDK runtime crates, I have created a changelog entry Markdown file in the .changelog directory, specifying "aws-sdk-rust" in the applies_to key.

---

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

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• Client Test (ignoring whitespace)
• No codegen difference in the Server Test
• Server Test Python (ignoring whitespace)
• No codegen difference in the Server Test Typescript

A new doc preview is ready to view.

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• Client Test (ignoring whitespace)
• No codegen difference in the Server Test
• Server Test Python (ignoring whitespace)
• No codegen difference in the Server Test Typescript

A new doc preview is ready to view.

[landonxjames]

Looks good, one question about feature management, but not a blocker.

Feel like this should release concurrently with the change from #4255 because that also feels like it might be an unexpected enough change to warrant a BehaviorVersion (I know the behavior version can't actually get that change since it is just a compile time dependency feature, but still feels like it should be indicated somehow)

[landonxjames]

Feels kind of weird adding tokio dependencies behind a flag that isn't rt-tokio. Would it make sense to introduce a rt-tokio flag that adds these deps and have these features enable that feature?

[aajtodd]

I think it depends on whether the feature is bringing in the tokio runtime as a requirement vs using tokio IO traits. (for example hyper-rustls also depends on tokio)

[aajtodd]

Feel like this should release concurrently with the change from #4255 because that also feels like it might be an unexpected enough change to warrant a BehaviorVersion (I know the behavior version can't actually get that change since it is just a compile time dependency feature, but still feels like it should be indicated somehow)

Feature flags and behavior versions are not the best match but ya we can discuss what makes sense.

[ysaito1001]

Feel like this should release concurrently with the change from #4255 because that also feels like it might be an unexpected enough change to warrant a BehaviorVersion (I know the behavior version can't actually get that change since it is just a compile time dependency feature, but still feels like it should be indicated somehow)

Feature flags and behavior versions are not the best match but ya we can discuss what makes sense.

Good point. My gut is this PR can go independently of PR4255; if we just upgraded rustls to 0.24 (say PR4255 didn't exist), we probably wouldn't add a new BehaviorVersion for a dependency upgrade.

[ysaito1001]

Awesome work. While dev guide could be useful, the API rustdoc seems good for now.

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• Client Test (ignoring whitespace)
• No codegen difference in the Server Test
• Server Test Python (ignoring whitespace)
• No codegen difference in the Server Test Typescript

A new doc preview is ready to view.

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• Client Test (ignoring whitespace)
• No codegen difference in the Server Test
• Server Test Python (ignoring whitespace)
• No codegen difference in the Server Test Typescript

A new doc preview is ready to view.

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• Client Test (ignoring whitespace)
• No codegen difference in the Server Test
• Server Test Python (ignoring whitespace)
• No codegen difference in the Server Test Typescript

A new doc preview is ready to view.

[github-actions]

A new generated diff is ready to view.

• AWS SDK (ignoring whitespace)
• Client Test (ignoring whitespace)
• No codegen difference in the Server Test
• Server Test Python (ignoring whitespace)
• No codegen difference in the Server Test Typescript

A new doc preview is ready to view.