Consider stripping the crate version when building dependencies

[ipetkov]

Originally discussed in #281

The crux of the issue is that we automatically inherit the crate's version attribute (from Cargo.toml) as the version of the buildDepsOnly derivation. The value is also not stripped when cleaning the Cargo.toml file. This unfortunately means that when a crate's version is updated (e.g. to publish a new release) it will invalidate the cache and require building all dependencies from scratch.

A more cache-friendly solution would be to replace version with a static placeholder value (both when cleaning the Cargo.toml and when setting the buildDepsOnly derivation's version attribute).

One possible downside of this is if a project uses a build command which somehow relies on the version of the crate (e.g. tries to parse something like cargo tree mycrate@x.y.z). I think there should be an escape hatch (such as doNotStripVersion = true; or equivalent) which would bring back the previous behavior if required

[ipetkov]

Some more observations on this: changing the versions of any Cargo.toml [package] definition would also need to subsequently change the respective Cargo.lock definitions as well, otherwise cargo will complain about the lockfile being out of date (since we pass in --locked)