Generate Cargo.lock before call `cargo audit`

[stefano-garzarella]

Summary of the PR

Starting from v0.18.0, cargo-audit hangs indefinitely if Cargo.lock does not exist. We discovered this while upgrading the container from v26 to v28 [1], which among other things updated cargo-audit.

For the binary crates this should not be a problem, since they have Cargo.lock committed, but for many libraries this may not be true.

If Cargo.lock is not there, we are generating one with the latest available versions, which may not be very significant. For this and other reasons it's now suggested that libraries also have a Cargo.lock [2] committed (thanks Manos for pointing this out).

Note: cargo generate-lockfile updates Cargo.lock if it's already there, but we don't want it, that's why we have the guard.

[1] https://github.com/rust-vmm/rust-vmm-ci/pull/138 [2] https://doc.rust-lang.org/nightly/cargo/faq.html#why-have-cargolock-in-version-control

Suggested-by: @epilys Suggested-by: @roypat

Requirements

Before submitting your PR, please make sure you addressed the following requirements:

• [x] All commits in this PR are signed (with git commit -s), and the commit message has max 60 characters for the summary and max 75 characters for each description line.
• [x] All added/changed functionality has a corresponding unit/integration test.
• [x] All added/changed public-facing functionality has entries in the "Upcoming Release" section of CHANGELOG.md (if no such section exists, please create one).
• [x] Any newly added unsafe code is properly documented.

[stefano-garzarella]

As we discussed in #138 , another option would be to skip cargo audit if there is no committed Cargo.lock or force to have one for libraries as well (but this last point maybe better in the future when we are sure everyone has it).