Add a check for new entries in the changes table to ensure swift syncing of non-Dexie observable changes.

[rtibbles]

Summary

Description of the change(s) you made

• Currently our handleChanges listener only triggers a sync when changes to our IndexedDBResource tables are made that are CREATE, UPDATE, or DELETE (the change types that Dexie Observable natively creates).
• This means that our custom change operations: MOVE, COPY, PUBLISH, and SYNC, will be ignored, until the sync endpoint polling happens.
• To remedy this, this PR implements an extra check in the handleChanges listener function to look for newly created changes in our specific changes table, so that we can trigger a sync when one of our custom changes has been created.

Manual verification steps performed

Carried out copy and move operations and confirmed that they were included in an almost immediate sync call to the backend.

Does this introduce any tech-debt items?

I don't think so - ultimately, I think we could drop Dexie Observable and use something closer to the Dexie middleware that it is built on top of to make a more unified solution.

References

Fixes #3586

[bjester]

So for @ozer550's websocket implementation, he should also check that synced on the underlying object is also false before sending a change to the backend? Unless I'm misunderstanding, changes coming from the backend would also cause this Dexie create change?

[bjester]

Actually, we don't save the incoming changes to IndexedDB. But we would apply them of course, so I'm just wondering how we ignore those changes that occur from incoming changes

[bjester]

I forgot about changes.filter(isSyncableChange); which would prevent the generation of changes from incoming events being applied.

[rtibbles]

I think still worthwhile to add the synced check here, to make sure we don't try to sync synced changes.