New feature: enable rustls-no-provider

[yawn]

💡 Motivation and Context

This avoids automatically pulling in aws-lc-rs which is quite heavyweight, requires a C toolchain etc.

Note that this change is breaking for everybody who uses this crate with default-features = false. Everybody else is unaffected.

💚 How did you test it?

Added an integration test and optionally (extra commit, feel free to drop it) a build/ci test.

📝 Checklist

• I reviewed the submitted code.
• I added tests to verify the changes.
• I updated the docs if needed.
• No breaking change or entry added to the changelog.

If releasing new changes

• Ran sampo add to generate a changeset file

[marandaneto]

thanks @yawn will take a look at it

[marandaneto]

we're planning the v1 major release with a few breaking changes, and since this has a breaking change if default-features = false we'd need to fit this in there, so people follow a proper migration before breaking things at runtime

[marandaneto]

blocking: Make the dependency-tree assertion fail closed\n\nNegating cargo tree makes any failure—including registry, dependency-resolution, or argument errors—look like proof that aws-lc-sys is absent, so this regression guard can pass silently. Please run cargo tree as a separately checked command, then inspect its successful output for aws-lc-sys.

[marandaneto]

suggestion: Update the documented E2E command\n\nCI now enables tls for E2E tests, but CONTRIBUTING.md still documents --features e2e-test --no-default-features. That leaves manual E2E runs without an HTTPS backend, so captures can fail while the test appears successful. Please update the documented command to include tls.

[marandaneto]

also:

Commits must have verified signatures

you have to sign the commits

[marandaneto]

moving to draft until we figure this out

[yawn]

also:

Commits must have verified signatures

you have to sign the commits

Oh, was that in the PR template? Sorry, must have overlooked it ...

[yawn]

moving to draft until we figure this out

I'd argue that this could still be a minor semver bump. It's not a breaking API change, it's just a non-breaking change (a simple remediation exists without functional implications) for a specific subset of users.