Add locked to various cargo build invocations for desktop

[faern]

We want to exit with an error if we try to produce a release build with an outdated lockfile. Such builds could be really hard to reproduce later, and is a supply chain risk. Being strict in CI is a good way of making sure we don't merge changes that require lockfile updates, but that were forgotten.

---

This change is 

[dlon]

Reviewed 4 of 4 files at r1, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @faern)

---

windows/nsis-plugins/src/log/log.vcxproj line 78 at r1 (raw file):

    </Link>
    <PreBuildEvent>
      <Command>powershell.exe -Command "&amp; { Remove-Item Env:VSTEL_MSBuildProjectFullPath; cargo build --target i686-pc-windows-msvc --release --locked -p mullvad-nsis }"

Same as above

---

windows/nsis-plugins/src/cleanup/cleanup.vcxproj line 78 at r1 (raw file):

    </Link>
    <PreBuildEvent>
      <Command>powershell.exe -Command "&amp; { Remove-Item Env:VSTEL_MSBuildProjectFullPath; cargo build --target i686-pc-windows-msvc --release --locked -p mullvad-nsis }"

This is actually the debug profile, even though the Rust code is always built in release mode. Is --locked needed?

[MarkusPettersson98]

Reviewed 2 of 4 files at r1, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @faern)

[faern]

Reviewable status: complete! all files reviewed, all discussions resolved

---

windows/nsis-plugins/src/cleanup/cleanup.vcxproj line 78 at r1 (raw file):

Previously, dlon (David Lönnhager) wrote…

This is actually the debug profile, even though the Rust code is always built in release mode. Is --locked needed?

The policy is that we should always use --locked when building artifacts that will be available to users or for internal testing. And from what I can find, we set the C++ profiles to Release when optimizations are enabled, which they always are on build servers. So it's fine to leave it out here. But it's a bit unclear connection between those. Would be easy to miss this special case if decided to not use optimizations on the build servers. But I guess we won't really.

[dlon]

Reviewed 4 of 4 files at r2, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved