feat: server-side client state persistence

[psychedelicious]

Summary

Move client state persistence from browser to server.

• Add new client state persistence service to handle reading and writing client state to db & associated router. The API mirrors that of LocalStorage/IndexedDB where the set/get methods both operate on keys. For example, when we persist the canvas state, we send only the new canvas state to the backend - not the whole app state.
• The data is very flexibly-typed as a pydantic JsonValue. The client is expected to handle all data parsing/validation (it must do this anyways, and does this today).
• Change persistence from debounced to throttled at 2 seconds. Maybe less is OK? Trying to not hammer the server.
• Add new persistence storage driver in client and use it in redux-remember. It does its best to avoid extraneous persist requests, caching the last data it persisted and noop-ing if there are no changes.
• Storage driver tracks pending persist actions using ref counts (bc each slice is persisted independently). If there user navigates away from the page during a persist request, it will give them the "you may lose something if you navigate away" alert.
  • This "lose something" alert message is not customizable (browser security reasons).
  • The alert is triggered only when the user closes the tape while a persist network request is mid-flight. It's possible that the user makes a change and closes the page before we start persisting. In this case, they will lose the last 2 seconds of data.
  • I tried making triggering the alert when a persist was waiting to start, and it felt off.
  • Maybe the alert isn't even necessary. Again you'd lose 2s of data at most, probably a non issue. IMO after trying it, a subtle indicator somewhere on the page is probably less confusing/intrusive.
• Fix an issue where the redux-remember enhancer was added last in the enhancer chain, which prevented us detecting when a persist has succeeded. This required a small change to the unserialze utility (used during rehydration) to ensure slices enhanced with redux-undo are set up correctly as they are rehydrated.
• Restructure the redux store code to avoid circular dependencies. I couldn't figure out how to do this without just smooshing it all into the main store.ts file. Oh well.

Implications:

• Because client state is now on the server, different browsers will have the same studio state. For example, if I start working on something in Firefox, if I switch to Chrome, I have the same client state.
• Incognito windows won't do anything bc client state is server-side.
• It takes a bit longer for persistence to happen thanks to the debounce, but there's now an indicator that tells you your stuff isn't saved yet.
• Resetting the browser won't fix an issue with your studio state. You must use Reset Web UI to fix it (or otherwise hit the appropriate endpoint). It may be possible to end up in a Catch-22 where you can't click the button and get stuck w/ a borked studio - I think to think through this a bit more, might not be an issue.
• It probably takes a bit longer to start up, since we need to retrieve client state over network instead of directly with browser APIs.

Other notes:

• We could explore adding an "incognito" mode, enabled via invokeai.yaml setting or maybe in the UI. This would temporarily disable persistence. Actually, I don't think this really makes sense, bc all the images would be saved to disk.
• The studio state is stored in a single row in the DB. Currently, a static row ID is used to force the studio state to be a singleton. It is possible to support multiple saved states. Might be a solve for app workspaces.

Related Issues / Discussions

n/a

QA Instructions

Try it out. It's pretty straightforward. Error states are the main things to test - for example, network blips. The new server-side persistence driver is the only real functional change - everything else is just kinda shuffling things around to support it.

Merge Plan

n/a

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Tests added / updated (if applicable)
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)