Track lockfile

[sftse]

This commit adds Cargo.lock to the set of tracked files.

The benefits of doing this are that a) changes to transitive dependencies like in #1756 become obvious, put gentle backpressure on compile time/version multiplicity and b) all contributors are on a single source of truth.

The only downside to this change from experience is that merge conflicts with Cargo.lock can be quite bad and require some knowledge to resolve. Usually, when rebasing A onto main the most likely thing one wants to do is retain the version of Cargo.lock from main, resolve the conflicts in Cargo.toml and build the project to let cargo figure out the new patch versions, then commit the newly generated Cargo.lock.

[ArthurZucker]

Thanks! We do force push this file when releasing. Not sure if it is worth it for dev

[sftse]

Feel free to close if you think it's not worth it. I think it is rather important to be able to reproduce the exact state in which the library was tested.
One example that can be unpleasant without a Cargo.lock is if one needs to find the point at which a regression was introduced. Dependencies that do accidentally introduce breaking changes in a patch version can make git bisect painful. It's not sufficient, granted, as one would also have to track the compiler version, but it's one step towards making it more automated.