Add lint to explicitly set resolver in a virtual workspace

[TheButlah]

Problem

Because the resolver is a global setting in workspaces, and workspaces don't have edition settings, I believe that it is very easy to accidentally use the old resolver in workspaces where you intended on using the new resolver. Because I didn't know about the resolver being global, I just assumed I was using the new one since my crate's edition said "2021" and it caused me to spend the last 4 days trying to fix my builds.

Proposed Solution

I think that having a lint in cargo that says "hey you should explicity set your resolver" would be merited. Because otherwise everyone is going to be using the old resolver all the time, perhaps even without realizing.

Notes

See also rust-lang/rust#90148 and #9996

[Eh2406]

There is an issue of people who are not using resolver so that their workspace is compatible with older Cargos. This becomes less of an issue overtime, but is still a thing. So maybe we worn on a 2021 crate being built in a workspace that did not set resolver.

[TheButlah]

Crates != workspace though, that's why the issue is here to begin with. It's not sufficient to set resolver =2 in the crates cargo.toml, it has to be done in the workspace Cargo.toml

I'm advocating for a lint that suggests explicitly setting the resolver (even if resolver = 1) in the workspace Cargo.toml

[johnkjellberg]

As a minimum, I think it would make sense to warn (or generate a error) if a crate explicitly sets resolver = 2, but it uses resolver v1 due a workspace in the root without a resolver set/resolver set to v1.

[DusterTheFirst]

Having the default workspace resolver as v1 creates confusion in workspaces with all crates using edition = "2021". Telling the user that the resolver might not match their expectation can save days of troubleshooting weird dependency problems as in my and @TheButlah's cases.

[Muscraft]

Part of workspace inheritance is the ability for a member to inherit the edition from its workspace. #10587 was opened to discuss if setting the edition in [workspace.package] should imply the resolver version for the workspace if one is not set. This might help mitigate this issue for users of workspace inheritance. If anyone has thoughts on this please add them to the issue.