Allow selecting AWS SDK TLS features

[dertin]

Description

Why is this change being made?

1. Some applications need to opt out of the AWS SDK service client default TLS feature set and select the SDK HTTP client features explicitly.

What is changing?

1. Adds crate features that forward to the AWS SDK default-https-client, rt-tokio, credentials-process, sso, and rustls features.
2. Keeps the current default feature behavior unchanged for existing users.
3. Documents how to use aws_secretsmanager_caching with default-features = false and the modern HTTPS client feature set.

Related Links

• Issue #, if available: N/A

---

Testing

How was this tested?

1. cargo check -p aws_secretsmanager_caching
2. cargo check -p aws_secretsmanager_caching --all-features
3. cargo check -p aws_secretsmanager_caching --no-default-features --features default-https-client,rt-tokio,credentials-process,sso
4. cargo test -p aws_secretsmanager_caching --no-fail-fast
5. cargo test -p aws_secretsmanager_caching --no-default-features --features default-https-client,rt-tokio,credentials-process,sso --no-fail-fast

When testing locally, provide testing artifact(s):

1. All commands above passed locally. Existing unused_parens warnings in tests are still present.

---

Reviewee Checklist

Update the checklist after submitting the PR

• I have reviewed, tested and understand all changes
  If not, why:
• I have filled out the Description and Testing sections above
  If not, why:
• Build and Unit tests are passing
  If not, why:
• Unit test coverage check is passing
  If not, why: Not run locally.
• Integration tests pass locally
  If not, why: Not run locally.
• I have updated integration tests (if needed)
  If not, why: Not needed; this only changes Cargo feature wiring and README docs.
• I have ensured no sensitive information is leaking (i.e., no logging of sensitive fields, or otherwise)
  If not, why:
• I have added explanatory comments for complex logic, new classes/methods and new tests
  If not, why: Not needed; no runtime logic was added.
• I have updated README/documentation (if needed)
  If not, why:
• I have clearly called out breaking changes (if any)
  If not, why: No breaking changes. Default features are kept unchanged.

---

Reviewer Checklist

All reviewers please ensure the following are true before reviewing:

• Reviewee checklist has been accurately filled out
• Code changes align with stated purpose in description
• Test coverage adequately validates the changes

[simonmarty]

This looks ok to me at first glance. Can you elaborate on your use case?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.14%. Comparing base (fda3e15) to head (3934127).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #197   +/-   ##
=======================================
  Coverage   92.14%   92.14%           
=======================================
  Files          14       14           
  Lines        2405     2405           
  Branches     2405     2405           
=======================================
  Hits         2216     2216           
  Misses        143      143           
  Partials       46       46           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[dertin]

Hi @simonmarty, thanks for asking.

My main use case is dependency-tree control for applications that explicitly manage the AWS SDK HTTP/TLS stack.

In our application, we want to use the SDK default-https-client + rt-tokio path consistently, without aws_secretsmanager_caching enabling the service-client rustls feature again through its default features.

This matters because enabling aws-sdk-secretsmanager/rustls still selects the legacy aws-smithy-runtime/tls-rustls path, which brings in the older hyper/rustls stack. What we want instead is to stay on the modern default-https-client path and avoid carrying the legacy rustls 0.21 stack in this part of the dependency graph.

At the moment, we need to keep temporary cargo audit ignores for advisories that are only present because this legacy TLS path is still being resolved: RUSTSEC-2026-0098, RUSTSEC-2026-0099, and RUSTSEC-2026-0104.

With this PR, existing users keep the current default behavior, while downstream applications can opt out explicitly by using aws_secretsmanager_caching with default-features = false and enabling only the SDK features they need.

For this TLS-selection use case, the following example should be enough:

aws_secretsmanager_caching = { version = "2", default-features = false, features = [
  "default-https-client",
  "rt-tokio",
] }

If an application relies on AWS profiles that use SSO or credential_process, it can add sso and/or credentials-process explicitly. They are useful options for compatibility with those credential-provider setups, but they are not required for the TLS-selection use case itself.