Use --locked for pre-build step of Dockerfile

[tpoliaw]

Ensures that the versions of dependencies used in the final build are
the same as those cached by the previous build.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 49.27%. Comparing base (a2eb617) to head (f436833).

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #104   +/-   ##
=======================================
  Coverage   49.27%   49.27%           
=======================================
  Files          13       13           
  Lines         621      621           
=======================================
  Hits          306      306           
  Misses        315      315           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ZohebShaikh]

This is will have no impact.

Here is my reasoning behind it.

1. Copy command is not cached so the Cargo.toml and Cargo.lock will always be the latest changes.

2. When both the cargo builds are ran they have the same files.

3. --locked only Assert that Cargo.lock will remain unchanged
   Which I think does not happen between those two cargo builds

Is there something obvious that I have missed ?

[tpoliaw]

You might be right but then I think the --locked in the second build is redundant as well.

I was mixing up the behaviour of cargo build and cargo install where --locked do different things. My original thinking was

1. Commit change that changes Cargo.toml/Cargo.lock but not to the latest version of something
2. The cache is invalidated so the pre-build runs again but without --locked brings in different versions than those in the lock file
3. The final build uses --locked so will have to rebuild all the different dependencies