Implements --refresh-lockfile

[arcanis]

What's the problem this PR addresses?

Lockfiles changes that are part of PRs submitted by third-parties may be compromised and contain metadata that don't match reality. This could lead to maintainers unknowingly starting to depend on packages they don't control / don't trust.

The current solution is to either review the whole lockfile (which is doable, but impractical for large changes, like when upgrading all @babel dependencies in a repository), regenerate the lockfile from scratch (high friction), or hope for third-party tools like Snyk to detect issues.

How did you fix it?

This diff adds a new flag, --refresh-lockfile, which will keep resolutions in place but will resolve the associated metadata anew (this is the same thing we do when we bump the lockfile version, to regenerate the missing fields).

Because both this flag and --immutable are enabled by default on PRs CI, projects upgrading to Yarn 4 will automatically be protected from compromised package metadata.

Checklist

• I have read the Contributing Guide.

• I have set the packages that need to be released for my changes to be effective.

• I will check that all automated PR checks pass before the PR gets reviewed.

[arcanis]

PR is still in draft because I need to remove another attack vector before this diff can be effective: it's still possible for an attacker to change a dependency resolution, which will lead Yarn to pull the compromised metadata.

To address this we'll need a way to check that the resolution is compatible with the range, which is easy enough for npm dependencies but a little more difficult for more complex schemes, like Git dependencies (we can't just call getCandidates and see if the resolution is one of the options, because it doesn't return what used to be valid, only what currently is, so if the repository receives new commit the resolution would be reported as invalid).

Edit: Now addressed by:

• Implements --check-resolutions #4302