Raise MSRV for `zcash_primitives` and its dependents

[str4d]

Our current MSRV for zcash_primitives is 1.56.1 (which was a security fix release that some of our dependencies raised their MSRV to).

rustls 0.20.8 bumped its MSRV to 1.57.0 (as a result of its own dependencies bumping MSRV). We only use rustls when the download-params feature of zcash_proofs is enabled, but that is part of our public API, so we now need to consider bumping our MSRV, and if we're going to bump for zcash_proofs then we should just bump for zcash_primitives and its dependents. (Component crates like zcash_encoding should be considered separately, given that they are going to be factored out.)

[str4d]

I performed some analysis to help guide our MSRV choice.

Features

I went through the release blog posts and picked out reasons we might want to set our MSRV to a specific version:

• 1.57 (n - 9):
  • panic! in const contexts, enabling static assertions.
  • Custom compiler profiles.
  • Fallible allocation APIs.
• 1.59 (n - 7):
  • Inline assembly.
  • Const generics defaults and interleaving.
  • std::thread::available_parallelism (replacing num_cpus crate).
• 1.60 (n - 6):
  • Weak dependency features and namespaced features.
  • Instant monotonicity guarantees (IDK if we rely on Instant anywhere though).
• 1.61 (n - 5):
  • More capabilities for const fn.
• 1.62 (n - 4):
  • #[default] enum variants.
  • bool::then_some
• 1.63 (n - 3):
  • Scoped threads.
  • const Mutex, RwLock, Condvar (enables avoiding lazy_static usage for creating global statics using these).
• 1.64 (n - 2):
  • C-compatible FFI types in core and alloc (for no-std usage).
  • Workspace inheritance.
• 1.65 (n - 1):
  • Generic associated types (GATs).
  • let-else statements.
• 1.66 (n):
  • Explicit discriminants on enums with fields.

Of these, I think weak dependency features has the strongest argument, as it fixes the problem where a downstream user can't enable certain combinations of feature flags without others (usually when trying to use an optional dependency in a no-std environment). Currently in places where we've had this problem, we've mitigated it by creating a full combinatorial matrix of feature flags; bumping MSRV to 1.60 would let us simplify it.

Dependencies

These are the MSRVs that we would need to upgrade to the latest versions of our dependencies:

• 1.57.0:
  • base64 0.21
  • bip0039 0.11
  • rustls 0.20.8
  • criterion 0.4
  • Their official policy is n - 2 (last 3 stable releases), which was 1.59 at time of publishing, but 1.57 does happen to work.
• 1.60.0:
  • primitive-types 0.12
• n - 4 (last six months):
  • time 0.3 (but we don't actually control this dependency)

I know that the RustCrypto crates are starting to move their crates to an MSRV of 1.60.0 in places where they benefit from weak features. This does not affect any of our dependencies on them yet, but it may make sense to sync up here.

History

Here's a summary of all the MSRVs we've had for these crates, and the range of supported minor Rust versions at the time of each bump:

Version	Released	When we bumped	Range at bump
1.37.0	2019-08-15	2019-10-08 (#138)	n - 1
1.39.0	2019-11-07	2019-12-12 (#188)	n
1.40.0	2019-12-19	2020-07-09 (#246)	n - 4
1.44.1	2020-06-18	2020-09-09 (#288)	n - 2
1.47.0	2020-10-08	2021-03-05 (#347)	n - 3
1.51.0	2021-03-25	2021-03-26 (#365)	n
1.56.1	2021-11-01	2022-02-24 (#516)	n - 3

So we've hovered around n - 3 (last 4 stable releases, around 18-24 weeks) as our "support window" for Rust, except for specific releases where we needed something the release provided (e.g. 1.51.0 had the const generics MVP). If we stuck with this cadence, we would pick Rust 1.63.0 as our next MSRV.

[sellout]

We only use rustls when the download-params feature of zcash_proofs is enabled

I started a Fun Friday a while back to get zcashd to use download-params internally (zcash/zcash#4491), rather than the separate Python script (but haven’t finished it). In any case, while there’s plenty of other motivation for the MSRV bump, I just want to point out that we should be using download-params (and thus rustls) much more.

[str4d]

Looking at the above, I'm inclined towards bumping our MSRV to 1.60:

• To resolve current breakage, bumping to 1.57 would be sufficient. But within the Zcash ecosystem (which is all we need to consider for zcash_primitives and its dependents), I don't personally see a need to have a support window that far back.
• 1.60 provides features that improve downstream developer experience, and I suspect will be the next focal point in the wider cryptographic crate ecosystem (the previous one being 1.56 which contained Rust 2021 edition).
• I don't see anything in 1.61-1.63 that strongly motivates sticking precisely to our average support window.
• I'm sure @nuttycom would have a field day with GATs, but I don't yet see them as a sufficiently motivating feature to justify the narrower support window (vs our 1.51 MSRV bump for const generics, which had a significant impact on the orchard crate's type safety).

[str4d]

We only use rustls when the download-params feature of zcash_proofs is enabled

I started a Fun Friday a while back to get zcashd to use download-params internally (zcash/zcash#4491), rather than the separate Python script (but haven’t finished it). In any case, while there’s plenty of other motivation for the MSRV bump, I just want to point out that we should be using download-params (and thus rustls) much more.

Note that for zcashd, our goal is to always be on the most recent version of the Rust compiler (so an MSRV support window of n). In practice that goal is tempered by our desire to use a single LLVM version, but in any case the MSRV of zcash_primitives is not a constraint on zcashd.

[nuttycom]

I don't have specific use cases for GATs at the moment, though I strongly suspect that will change with the next revision of the wallet code; I have a couple places there in mind where they could help clean up the design. 1.60 sounds good to me.

[str4d]

the MSRV of zcash_primitives is not a constraint on zcashd.

The converse is true however. zcashd is currently stuck on Rust 1.64, because 1.65 bumped to LLVM 15 and we can't upgrade to Clang 15 yet (due to LLVM upstream not providing the necessary binary packages).

[daira]

If we can't have 1.65 (with GATs), then I agree with choosing 1.60, because it doesn't look like there is anything added in 1.61..=1.64 that we especially need.

[daira]

Note that the current version (that we don't depend on yet) of cxxbridge depends on a version of clap with an MSRV of 1.64.0: https://github.com/dtolnay/cxx/issues/1152