Document MSRV Policy

[briansmith]

Strawman:

• For the next (imminent) release, bump MSRV to 1.61 to enable most const fn goodness and newer dependencies.
• Provisionally to avoid bumping MSRV past a versoin that isn't at least 6 months old which would let us bump the MSRV up to 1.68 now, 1.69 in a few weeks, and 1.70 in a few months.
• Flesh out an official policy and document that policy in README.md.

We would very much like to use Rust 1.70 as the minimum as soon as we get agreement so that we can use OnceCell and drop the external dependency though. So perhaps we could agree that 1.70 could become the MSRV sooner.

@djc @ctz @cpu @joshlf

[briansmith]

PR #1540 will updated MSRV to 1.61.

[djc]

I would probably prefer adding the once_cell dependency for the next few releases and holding off the bump to 1.70 until December (when it becomes 6 months old). Practically, it will already be a part of many dependency graphs anyway.

[briansmith]

Another nuance: We should probably strive for a warning-free build when using the latest stable toolchain (and not necessarily nightly or beta), but I don't think it is reasonable to guarantee a warning-free build for versions as far back as the MSRV. If nightly/beta toolchains add a warning that we need to address before stable, we should do so before the stable toolchain release, whenever practical. In theory, there might be difficult cases where pre-stable toolchains add a warning that can only be resolved by using pre-stable coding patterns, but I expect that would be rare.

This comes up in particular where we may reference lints that are present in the latest stable toolchain release, but which aren't present in earlier toolchains. In this case, when building with the earlier toolchains we might trigger the unknown_lints warning. We don't want to #[allow(unknown_lints)] unconditionally, but only with older toolchain versions. I will suggest a solution for this in #1895 that somebody could contribute. So I think we can eventually get to the point where we never trigger unknown_lints on stable or older toolchains.

Besides those the unknown_lints, I guess we'd have to see on a case-by-case basis how to handle warnings that occur in older toolchains but not in newer toolchains.

In fact, we may want to intentionally issue warnings in some cases. For example, it seems like a pretty bad idea to be using a pre-1.65.0 toolchain when building for AAarch64 because of the C/Rust ABI compatibility bug. (Luckily, I don't think we're using 16-bit types anywhere in the Rus FFI boundary so this doesn't affect us, though this is almost pure luck.)