Eliminate transitive OpenSSL dependency; unblock CI/release

[pizzle85-maker]

What

Closes #290 (Deprecated OpenSSL 1.1.1 Dependency on Linux) and gets CI/release infrastructure back into a working state, which appears to be why no release has shipped since v2.0.7 (2024-05-20) despite real fixes landing on master since then.

Commit 1 — the actual OpenSSL fix

teller-providers depends on both vaultrs (which already defaults to the rustls TLS backend) and rustify directly. rustify was left on its own default features, which select reqwest's native-tls backend. Because Cargo unifies features across the whole dependency graph, this silently pulled openssl-sys/native-tls back into the final binary even though vaultrs had already opted out of it.

Pinning both vaultrs and rustify to their rustls/rustls-tls features (and disabling default features) removes openssl-sys from the dependency tree entirely — confirmed with cargo tree --invert openssl-sys (zero matches) and ldd on the resulting release binary (no libssl dependency at all, vs. today's v2.0.7 binary which requires the long-EOL libssl.so.1.1).

This also explains why the released binary links 1.1.1 specifically: the x86_64-linux Dist job runs on ubuntu-20.04, whose system OpenSSL is 1.1.1 — native-tls just links whatever the build host has. It was never an intentional pin to 1.1.1.

Commit 2 — unblock CI so a release can actually be cut

• actions-rs/toolchain/actions-rs/cargo are from an org archived since November 2021 — replaced with dtolnay/rust-toolchain + plain cargo invocations. This is almost certainly the real cause of the "fix build?" commits in January not sticking — master's CI has been red since then.
• actions/upload-artifact@v2 / actions/download-artifact@v2 stopped working entirely on 2025-01-30 (GitHub fully shut off the v1/v2 APIs). Bumped to v4 in release.yml — without this, the Dist/Publish jobs cannot complete even if a tag is pushed today.
• release.yml's x86_64-linux Dist job was pinned to ubuntu-20.04, a runner image GitHub has since retired. Bumped to ubuntu-22.04.
• Replaced the deprecated ::set-output:: workflow command with $GITHUB_OUTPUT.
• Fixed the 3 cargo clippy errors and 1 stale rustfmt spot that were failing the Lints job, plus one stale trycmd test snapshot (delete.trycmd) that no longer matched current error-message formatting.

Verification

Built and tested locally end-to-end (Rust 1.98, protoc installed):

• cargo build --release --locked -p teller — succeeds; ldd target/release/teller shows no libssl* dependency.
• cargo fmt --all -- --check — clean.
• cargo clippy --all-features -- -D warnings -W clippy::pedantic -W clippy::nursery -W rust-2018-idioms — clean.
• cargo test --all-features --all (teller / teller-core / teller-providers) — all green, except providers::etcd::tests::sanity_test, which is unrelated to this PR: Bitnami removed the bitnami/etcd image from Docker Hub entirely in their 2025 catalog restructuring (bitnami/etcd now has zero tags on Docker Hub at all — confirmed via the registry API). That test needs a different container image; left out of scope here since it's a separate maintainer judgment call, not a build/OpenSSL issue.

Happy to split this into two PRs (fix vs. CI) if that's easier to review, or to open a separate issue for the etcd/Bitnami test breakage if useful.

🤖 Generated with Claude Code

[pizzle85-maker]

@jondot — flagging this directly since I know GitHub notifications are easy to miss. This closes out #290 (OpenSSL 1.1.1 dependency, open since June 2024) and, maybe more usefully, fixes the exact CI breakage you were fighting on Jan 27 (the "fix build?" commits) — actions-rs/toolchain/actions-rs/cargo are from an org archived since 2021, and that's what's been making master's Build workflow flaky/red since then.

Also worth knowing regardless of what happens with this PR: release.yml can't currently produce a release even with a clean tag push — actions/upload-artifact@v2/download-artifact@v2 were fully shut off by GitHub on 2025-01-30 (not just deprecated, the API calls fail outright). That's independent of this PR and would block v2.0.8 either way, so I bumped those to v4 here too.

Everything's built, tested, and verified locally (details in the PR description) — happy to split into smaller PRs, adjust anything, or just answer questions if that helps it move.