Add `rust-version` into `Cargo.toml`

[polarathene]

Is your feature request related to a problem? Please describe.

Similar to #948

But using rust-version instead with releases, as it minimizes the MSRV concern by minimizing effort to create a compatible lockfile.

Describe the solution you'd like

Adopt rust-version in Cargo.toml.

• It'll display the minimum supported Rust version on crates.io versions tab for Warp.
• Tools like cargo-upgrade, cargo add and cargo +nightly update -Z msrv-policy can leverage this information to better resolve a release in semver that is compatible.

Describe alternatives you've considered

Version pinning in Cargo.toml or manually managing pinning with Cargo.lock generation.

Additional context

-Z msrv-policy minimizes the effort when crates properly publish and maintain declared rust-version, minimizing the issue of semver resolving point releases with MSRV bumps.

When an MSRV is not known, you can usually get away with cargo-msrv command on your crate to detect the lowest version that is compatible, then add that as the rust-version. Whenever that would become incompatible, just bump it up again with the next release, no worries 👍

rust-version is just a guidance of what should be possible to build the crate with. Sometimes like with hashbrown 0.14.2 this may require pinning some dependencies. It does not need to be raised when dependencies bump the MSRV implicitly, if they adopt rust-version too and update it correctly the whole issue is avoided.

rust-version only needs to be updated when you explicitly introduce changes into the project that would require a newer version of rust to build. It's important to try keep that accurate, otherwise the resolver advantage from rust-version becomes less useful (recent example with tokio-util).

[polarathene]

You also manage reqwest where MSRV was raised to 1.63 due to tokio, but the dependency in reqwest is tokio = "1", thus that is not exactly accurate for rust-version, and could possibly have been kept lower.

---

reqwest can have an MSRV policy AFAIK that would only support users with Rust on 1.63, but the rust-version bump is a bit inaccurate unless you're using a feature from tokio that actually required building with at least Rust 1.63, and could not resolve an earlier release of tokio where it'd have been compatible on earlier Rust toolchains.

Since tokio already adopts rust-version, you could more easily verify that in CI with cargo +nightly update -Z msrv-policy, which for example would fail cargo +version_here check --tests if any dependencies for reqwest did not resolve. There is the occasional hiccup as linked earlier with tokio-util, which would either require you to raise your own rust-version or manage a Cargo.lock.

Ideally you only need to bump rust-version when a change like tokio-util 0.7.9 introduced required it, or updating a dependency that raised it's own rust-version where -Z msrv-policy may not be sufficient (eg: upgrading hashbrown to newer minor release bump like hashbrown 0.14).