Implement sync locking based off message acknowledgment and returned changes #4161
Description
Depends on: #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.