[Refactor ensureStateIsUpToDate] split into two modes for when to recompute state

[savil]

Summary

Refactor the implementation of ensureStateIsUpToDate as per the suggestion in this comment: #1692 (comment)

1. Split lockfile.Save into lockfile.Save and lockfile.UpdateAndSaveStateHash
2. For now, regardless of recomputeState (boolean variable), we always call recomputeState (the function). In the next PR, this will change.

NOTE:
In pluginManager.create, I only do lockfile.Save and not lockfile.UpdateAndSaveLocal (as before), because:
When I do devbox add php81Extensions.ds then the lockfile.Save in pluginManager.Create here is resulting in the local.lock being up-to-date so that the next devbox run is thinking everything is up to date and early returning in ensureStateIsUpToDate.

How was it tested?

devbox shell
devbox add hello
devbox rm hello

tests should pass.

[savil]

Current dependencies on/for this PR:

• main
  • PR [Refactor ensureStateIsUpToDate] split into two modes for when to recompute state #1723 👈
    • PR Derive nix profile from flake: attempt 2 #1724
      • PR [package outputs] generate buildInputs for package-outputs in flake #1721

This stack of pull requests is managed by Graphite.

[mikeland73]

I'm not sure removing lock.Save() from plugin manager is great. It modifies the lock file so I would expect it to save it?

When I do devbox add php81Extensions.ds then the lockfile.Save in pluginManager.Create here is resulting in the local.lock being up-to-date so that the next devbox run is thinking everything is up to date and early returning in ensureStateIsUpToDate.

Why is the case?

If it only saves the lockfile but does not update the local cache state, would the local state not be out of date?