Config support for controlling MSRV-aware resolver

[epage]

Split out of #9930 for RFC #3537 for a more focused conversation

We need a config field but this was left undefined in the RFC

[epage]

The RFC proposed

[build]
resolver.precedence = "rust-version"  # Default with `v3`

with the following values (on first release)

• maximum
• rust-version (falls back to rustc version if not present)

Future possibilities

• Dependencies resolution with --minimal-versions #5657 could add a minimum
• rustc for saying to resolve to the rustc version
• In the future, people might want to specify specific versions (Generate "Cargo.lock" for old Rust compiler #13503)

[epage]

For rustc value, I think we should see how to align with the package.rust-version = "tbd" field so people can connect the dots more easily.

Like with term (#13337), I wonder if we should be doing more individual fields rather than be-all fields.

Something like:

[resolver]
maximum = <true|false>
rust-version = <true|false|manifest|toolchain|<X>.<Y>.<Z>>
# yanked = <allow|ignore>
# prerelease = <allow|ignore>

This would also give control over #13290, #4225

We can have a separate [install.resolver]

Thoughts

• I'd prefer more consistency in field names and values
• I'd like to cover cases of "deny <incompatible|yanked|prerelease>", "discourage <...>", "allow <...>"
• To satisfy the above two, i suspect we should break out the "max rust version" from the "rust version policy" fields

This leads to something like

[resolver]
maximum = <true|false>
incompatible-rust-version = <deny|discourage|allow>
yanked = <deny|discourage|allow>
prerelease = <deny|discourage|allow>

rust-version = <workspace|toolchain|<X>.<Y>.<Z>>

• Not thrilled with the names
• Not liking the location of rust-version as it should also apply to cargo add (but not cargo check?)
  • Maybe [build] could have its own rust-version field
  • Maybe we could call this table [dependencies] and have it apply to cargo add?

[epage]

I wonder if, instead of maximum = <true|false> with minimum being what you get with maximum = false, if it'd be better to have a <something> = <maximum|minimum>.

[epage]

Talking this through with @Eh2406

• Fewer fields offers a higher level experience with a combinatoric problem
• More fields offers a lower level experience, allowing people to build what they want, but some combinations might not make sense

There isn't really much pushing us one direction or the other, so one way to look at this is which way is easier to evolve. Having fewer fields makes it so we can change it so that field sets defaults on the others. Having more fields makes that a little messier.

Current proposal

[resolver]
precedence = "<maximum|rust-version>"
# precedence = "<maximum|rust-version|minimum>"
# future: rust-version = "<workspace|toolchain|<X>.<Y>.<Z>"