move: bump Move.lock files in framework packages

[rvantonder]

Description

Stacked on #15166.

Ran sui move build in framework-packages.

Test Plan

N/A

---

If your changes are not user-facing and not a breaking change, you can skip the following section. Otherwise, please indicate what changed, and then add to the Release Notes section as highlighted during the release process.

Type of Change (Check all that apply)

• protocol change
• user-visible impact
• breaking change for a client SDKs
• breaking change for FNs (FN binary must upgrade)
• breaking change for validators or node operators (must upgrade binaries)
• breaking change for on-chain data layout
• necessitate either a data wipe or data migration

Release notes

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
mysten-ui	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 8, 2023 11:36pm
sui-core	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 8, 2023 11:36pm
sui-typescript-docs	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Dec 8, 2023 11:36pm

3 Ignored Deployments

Name	Status	Preview	Comments	Updated (UTC)
explorer	⬜️ Ignored (Inspect)	Visit Preview		Dec 8, 2023 11:36pm
multisig-toolkit	⬜️ Ignored (Inspect)	Visit Preview		Dec 8, 2023 11:36pm
sui-kiosk	⬜️ Ignored (Inspect)	Visit Preview		Dec 8, 2023 11:36pm

[rvantonder]

we track other packages in sui-framework so deepbook should be included as well

[amnn]

The change seems fine to me, but does this mean that moving forward we'll need to make this part of the release process or something? (i.e. how does toolchain versioning work for system packages?)

[rvantonder]

i.e. how does toolchain versioning work for system packages?

Good question, I'm running into some of this with the implementation too. Let me fold that into a larger discussion that I'll raise in slack. My overall take is: if we verify against on-chain system packages, it would imply we're using the latest version (and we can bake that into our versioning implementation with or without checking Move.lock).

Right now, if #15166 goes live, system package builds will modify Move.lock, so it makes sense to check in, which is the main reason behind this change. At the same time, we haven't always checked in changes digest changes either, so we could punt / ignore this Move.lock depending on how we treat it in toolchain versioning. In essence, writing this to the lock doesn't imply we need to use or make this part of the release process yet, until we discuss more. My sense is it that updates will likely just count as good hygiene.

[amnn]

Got it, thanks for the context! If we do go down the route of checking in these changes, we should probably also have a CI check (or update the existing changed_files.sh one) to make sure that a necessary lock file update was checked in.