Implement sync locking based off message acknowledgment and returned changes

Depends on: https://github.com/learningequality/studio/issues/3630

Desired behavior

When syncing to the backend, we want to make sure that we avoid syncing duplicate changes. We have proper defensive protection on syncing duplicate changes but they would cause errors to be thrown that could cloud our error reporting.

When a particular change is synced to the backend, we want to make sure that no other tab or connection picks up the same change, which could happen if multiple tabs have their own websocket connection and the user's connection to server gets interrupted. In this situation, the frontend should close and reopen the connection, but at the start should call the existing syncChanges to get up-to-date. This process could pick up other changes that were pending acknowledgement from the server.

Additionally, with multiple tabs open for the same channel, each would have its own websocket connection, so we want to make sure that returned changes from the connections are deduplicated. By locking the application of returned changes, and validating that the returned change hasn't already been applied, we can ensure that we don't also produce errant errors on the frontend.

Start by reading the dependency in issue 3630 and locating the existing syncChanges entry point. Trace reconnects and returned changes across multiple tabs or websocket connections; done means duplicate pending or returned changes are not synced or applied and no errant frontend errors are produced.