Guard against incompatible combination of sync calls

Is your feature request related to a problem? Please describe.
Currently it's possible to sync and additionally do sync_once after it. This can have side-effects such as

1. your sync that arrives second might get thrown out because we already handled the sync with that token
2. your sync that arrives second might be the same one as the one that gets currently processed, overwriting stuff that's already written, a ~costly noop
3. your sync that arrives second might be newer than what is currently being processed, i think that this might be fine, you're just overwriting the latest state
4. your sync that arrives second might be older than the current sync, overwriting new state with old state

Describe the solution you'd like
Doing a sync call which might have side-effects could error or panic. In the specific case of doing a sync first, it could set a flag internally that a sync is running, and a sync_once call happening after that could then error or panic if the sync flag is set.

Matrix context: https://matrix.to/#/!iYnZafYUoXkeVPOSQh:matrix.org/$SJv7N73YFIg9UAlfxIfaUUYI4U13EIyi06Foq3m6wsg?via=matrix.org&via=famedly.de&via=kde.org

Start by locating the sync and sync_once APIs and reading how they track or process sync state. Determine how an incompatible second call should be reported, including the cases described in the issue, then add coverage that verifies the chosen behavior for each relevant call combination.