Bug Fix: (SynchronizationDataService / WebSocketDataOperationService) Fix issue where object syncing promise returns before object transactions are saved.

[tejaede]

There is an issue where SynchronizationDataService requests a snapshot for an object from destinationDataService before the snapshot has been recorded. Note that this issue is intermittent and non-deterministic. It may not happen for all objects and it may not happen every time.

The expected flow of data

1. originDataService dispatches a ReadCompletedOperation
2. SynchronizationDataService captures ReadCompletedOperation
3. SynchronizationDataService attempts to sync the operation data to the destinationDataService.
   1. Register objects as "tracked" so that any changes to those objects are synced
   2. Map objects from rawData.
      1. This triggers change events on the objects
      2. Because the objects are "tracked", the changes are added to a Transaction
      3. destinationDataService passes the Transaction to the worker
      4. When transaction completes, we record a snapshot of the object
4. SynchronizationDataServiceexplicitly callsmainService.saveChanges()` which should wait for the transaction created in step 3->ii->b to complete. Meaning the object's snapshot has been recorded.
5. Retrieve the snapshot from the destinationDataService

The issue is that occasionally mainService.saveChanges() (in step 4) resolves before the Transaction created in step 3->ii->b is complete and the snapshot is therefore not available. This is currently worked around by explicitly waiting for pending transaction promises using DataService.pendingTransactionPromiseForObjects: https://github.com/PhrontHQ/mod/blob/main/data/service/mux/synchronization-data-service.js#L1237

The goal of this ticket is to determine how mainService.saveChanges() can resolve before the existing pending transactions have completed.

[tejaede]

The issue is that DataService.saveChanges() explicitly does not wait for all pendingTransactions to complete before it resolves. The current logic is

1. If there are no changes, (createdObjects, changedObjects, deletedObjects are empty) saveChanges() waits for all pending changes
2. If there are new changes, saveChanges() creates a new transaction and waits for only that new transaction to resolve. (
   1. The new transaction will wait for pendingTransactions that include the same objects.

The proposed fix is to create a transaction (or transactions) up front and add related objects to it.

Phase 1
Refactor DataService so it creates a Transaction by default and then adds dataObjectChanges, createdDataObjects, changedDataObjects and deletedDataObjects directly on the transaction. When someone calls saveChanges, that transaction is sent immediately and a new default is created.

Phase 2
Support additional transactions that manage certain parts of the subgraph. E.g. when an object is synced in SynchronizationDataService, we collect all creations/changes for that object on the same transaction. This will allow changes elsewhere in the app to be saved without prematurely saving changes for objects still being synced.