cargo: track Cargo.lock again

[martinpitt]

3de34fc dropped the lock on the reasoning in systemd/zram-generator#65:
semantic version ranges plus upstream compatibility promises should be
enough, naming exact versions claims they are better than others without
evidence, and Fedora distro builds ignore the lock anyway.

However:

• We do not build from version ranges alone. tokio-vsock comes from git
  at rev c6225086, so a checkout already rests on one exact revision.
  The lock is what records the other 306.

• Our RPM is also not the distro build that reasoning had in mind. It
  runs rpmbuild --build-in-place over this worktree and resolves
  crates from crates.io as it goes, so it reads whatever lock is
  present rather than a set of versions the distro chose.

We want Cargo.lock for:

• reproducible builds outside of Fedora/rpm packages
• building with build systems like https://buck2.build/ which have a
  strict "input file hash" change semantics
• move "surprise" regressions from unsuspecting unrelated PRs to the
  specific dependabot PR that bumps a dependency, to make these changes
  reviewable and bisectable.

Pass --locked everywhere dependencies get resolved, so a lock that has
drifted from Cargo.toml fails the build instead of being quietly
rewritten.

Signed-off-by: Martin Pitt martin@amutable.com

---

Plus the corresponding dependabot config update in the second commit.

[mvo5]

[..]

* The size gates: varlink-httpd sits at 3966KB against a 4096KB limit,
  varlinkctl-http at 1793KB against 2048KB. We are at 97% of budget, so an
  unrelated transitive crate growing a few hundred KB turns `just check`
  red on an unsuspecting run that changed nothing in Cargo.toml, and
  with a floating graph there is no way to tell that apart from a
  regression the commit under test introduced. Bisecting any such
  regression needs the other 305 packages to hold still; our manifests
  name only 30 of them.

[..]

With the recent merge of #80 the budget got a lot better. In general I do not disagree but at the same time I think its okay if things break when the size increases too much so that we can eval what to do about it. With the updated budget it should be much less fragile now.

[martinpitt]

@mvo5 ack -- I'm happy to remove that point from the commit message of course. It previously stood out as a trap that will bite us soon, but not any more with #80.

[martinpitt]

Dropped that size trap.

[martinpitt]

Fixed up the dependabot config. I just learned about that trap in a different project.

[keszybz]

reproducible builds outside of Fedora/rpm packages

Actually Cargo.lock does not make builds reproducible, since the compiler version is not locked down.

Also, the motivation to drop Cargo.lock is not only about rpms. We have two choices, either we use something like dependabot and we end up with endless noise in the git history, or we constantly have outdated refs.

But if we need this to make buck builds work, then let's do it.

[martinpitt]

@keszybz note the second commit here sets up dependabot. We need that anyway to also bump the dependencies in Cargo.toml.