Support rangeStrategy=update-lockfile for Cargo

[rarkins]

Describe the proposed change(s).

Support in-range dependency updates for Cargo manager

Describe why we need/want these change(s).

Cargo's semver approach is different from most others. For example if a value like 1.0.0 is specified then it means the same as ^1.0.0 in npm, i.e. >=1.0.0, <2.0.0. This means that in-range, lockfile-only updates should be the most common use case. Today we use bump but it means unnecessarily narrowing the package file

[rarkins]

Cc @Turbo87

[rarkins]

Here is the docs for cargo update: https://doc.rust-lang.org/cargo/commands/cargo-update.html

Today we use this:

--workspace

Attempt to update only packages defined in the workspace. Other packages are updated only if they don’t already exist in the lockfile. This option is useful for updating Cargo.lock after you’ve changed version numbers in Cargo.toml.

We hopefully could use this for in-range updates:

--precise

When used with -p, allows you to specify a specific version number to set the package to. If the package comes from a git repository, this can be a git revision (such as a SHA hash or tag).

[szlend]

I've been looking at what it would take to do this and it doesn't seem as simple as it looked on the surface. Correct me if I'm wrong, but what I could gather so far is:

• To update a package in Cargo.lock in-range (without touching the version spec in Cargo.toml), we need to know the current version of the package, and the target version of the package. This is because you can have multiple versions of the same package in your dependency tree and you need to specify which one you're trying to update. We need to run something like cargo update ... --package <pkg>@<cur_ver> --precise <new_ver>. Using --workspace doesn't help with duplicates here.
• Currently renovate only looks at Cargo.toml, so it has no idea what the current version of a package even is.

So I think this means we'd first need to redesign the version extraction logic so it also takes Cargo.lock into account.

[rarkins]

There is a precedent for this: other managers extract a lockedVersion value which is used to compute this.

[szlend]

I think I have everything in place, I just can't seem to figure out a reliable way of getting the lockedVersion of a package without using cargo tree. I assume we shouldn't be execing commands in extractPackageFile because there's no way to get rust.constraints, right? I don't see any other manager doing that.

Edit: Using getSatisfyingVersion from versioning/cargo might do the trick.

[szlend]

Work in-progress here: #23968.

I haven't tested it on an actual repo yet, but would appreciate feedback if there's anything missing or wrong on a high-level.

[rami3l]

@rarkins Would you mind closing this issue? Thanks 🙏