[Rust] aws-db-esdk enables the deprecated rustls feature of aws-sdk-dynamodb / aws-sdk-kms, forcing vulnerable rustls-webpki 0.101.7 on all downstream users

## Summary

`aws-db-esdk` depends on `aws-sdk-dynamodb` and `aws-sdk-kms` without `default-features = false`.
For both crates the default feature set is `["rustls", "default-https-client", "rt-tokio"]`, and the deprecated `rustls` feature enables the legacy hyper-0.14 HTTPS stack:

```
aws-sdk-dynamodb/default -> rustls -> aws-smithy-runtime/tls-rustls
-> aws-smithy-http-client/legacy-rustls-ring -> rustls 0.21 -> rustls-webpki 0.101.7
```

`rustls-webpki` 0.101.7 is affected by three RustSec advisories, none of which have a fix available in the 0.101 line:

| Advisory | Summary |
| --- | --- |
| [RUSTSEC-2026-0098](https://rustsec.org/advisories/RUSTSEC-2026-0098) | Name constraints for URI names were incorrectly accepted |
| [RUSTSEC-2026-0099](https://rustsec.org/advisories/RUSTSEC-2026-0099) | Name constraints were accepted for certificates asserting a wildcard name |
| [RUSTSEC-2026-0104](https://rustsec.org/advisories/RUSTSEC-2026-0104) | Reachable panic in certificate revocation list parsing |

## Version

- `aws-db-esdk` 1.3.0 (also reproduces on 1.2.4)
- Resolved transitively: `aws-sdk-dynamodb` 1.120.0, `aws-sdk-kms` 1.114.0, `aws-smithy-runtime` 1.12.1, `aws-smithy-http-client` 1.2.0
- `cargo` 1.97.1, `cargo-deny` 0.19.0
- macOS (aarch64), but the resolution is platform independent

## Steps to reproduce

`Cargo.toml`:

```toml
[package]
name = "repro"
version = "0.1.0"
edition = "2021"

[dependencies]
aws-db-esdk = "1.3.0"
```

```console
$ cargo tree -i rustls-webpki@0.101.7
rustls-webpki v0.101.7
└── rustls v0.21.12
├── aws-smithy-http-client v1.2.0
│ └── aws-smithy-runtime v1.12.1
│ ├── aws-config v1.10.1
│ │ └── aws-db-esdk v1.3.0
│ │ └── repro v0.1.0
│ ├── aws-runtime v1.9.1
│ │ ├── aws-config v1.10.1 (*)
│ │ ├── aws-sdk-dynamodb v1.120.0
│ │ │ └── aws-db-esdk v1.3.0 (*)
│ │ ├── aws-sdk-kms v1.114.0
│ │ │ └── aws-db-esdk v1.3.0 (*)
...
```

For contrast, depending on the same SDK crates directly with default features disabled resolves only to a patched `rustls-webpki`:

```toml
[dependencies]
aws-sdk-dynamodb = { version = "1.120.0", default-features = false, features = ["default-https-client", "rt-tokio"] }
aws-sdk-kms = { version = "1.114.0", default-features = false, features = ["default-https-client", "rt-tokio"] }
```

```console
$ cargo tree -e all | grep -o "rustls-webpki v[0-9.]*" | sort -u
rustls-webpki v0.103.14
```

The two feature edges that enable the legacy stack can be confirmed with:

```console
$ cargo tree -e features -i aws-smithy-runtime
...
│ └── aws-smithy-runtime feature "tls-rustls"
│ ├── aws-sdk-dynamodb feature "rustls" (*)
│ └── aws-sdk-kms feature "rustls" (*)
```

In both cases the feature comes only from `feature "default"`, which is enabled only by `aws-db-esdk`.

## Why this cannot be worked around downstream

Cargo unifies features per crate, so a single dependency enabling `rustls` builds `aws-smithy-runtime` with `tls-rustls` for the entire graph.

In our workspace every AWS SDK crate we depend on directly already uses `default-features = false` with only `default-https-client` and `rt-tokio` enabled, exactly as recommended in [awslabs/aws-sdk-rust#1257](https://github.com/awslabs/aws-sdk-rust/discussions/1257) under *"How do I disable compiling the legacy hyper + rustls crates?"*. The legacy stack is still compiled in, purely because `aws-db-esdk` re-enables it. Removing `aws-db-esdk` from our dependency graph makes `rustls` 0.21 and `rustls-webpki` 0.101.7 disappear entirely.

We do not use the legacy hyper-0.14 connector at all — our clients are built with the default HTTPS client.

## Suggested fix

Rather than dropping the legacy stack outright, `aws-db-esdk` could mirror what [awslabs/aws-sdk-rust#1257](https://github.com/awslabs/aws-sdk-rust/discussions/1257) says the SDK crates themselves will eventually do: take it out of the default feature set, but keep it reachable through an explicit opt-in feature.

The announcement notes that the legacy stack is currently in the defaults so that pinning to an older `BehaviorVersion` works without extra configuration, and that once `rustls` leaves the defaults *"users will have to re-enable the `rustls` feature manually at that time to keep the behavior version working."* Exposing an equivalent feature on `aws-db-esdk` keeps that path open for anyone who needs it, while letting everyone else drop the duplicated TLS stack.

In both the runtime manifest and the published copy:

- `DynamoDbEncryption/runtimes/rust/Cargo.toml`
- `releases/rust/db_esdk/Cargo.toml`

```toml
[dependencies]
aws-sdk-dynamodb = { version = "1.103.0", default-features = false, features = ["default-https-client", "rt-tokio"] }
aws-sdk-kms = { version = "1.98.0", default-features = false, features = ["default-https-client", "rt-tokio"] }

[features]
default = ["non-fips"]
# Opt back in to the deprecated hyper-0.14 + rustls 0.21 stack, e.g. when pinning
# to a BehaviorVersion older than v2025_01_17.
legacy-https-client = ["aws-sdk-dynamodb/rustls", "aws-sdk-kms/rustls"]
```

`default` for those SDK crates is `["rustls", "default-https-client", "rt-tokio"]`, so this preserves current behaviour except that the legacy stack becomes opt-in.

Whether this warrants a major version bump of `aws-db-esdk` is your call — it is a behaviour change for users relying on feature unification, which is the same concern raised in that announcement's comment thread.

If keeping the legacy stack on by default is preferred for now, even just making it *switchable* (so downstream can build without it) would be enough to unblock users like us.

## References

- [awslabs/aws-sdk-rust#1257 — Announcement: Changes to the default HTTPS client stack](https://github.com/awslabs/aws-sdk-rust/discussions/1257)

Compare the dependency and feature definitions in DynamoDbEncryption/runtimes/rust/Cargo.toml and releases/rust/db_esdk/Cargo.toml. Run the issue's cargo tree checks to confirm which features pull in the legacy rustls stack. Done means the default SDK features no longer enable it while an explicit legacy-https-client feature preserves opt-in support.

Written by the indexing model from the issue text.