fix: Rare User and Subscription creates and updates processing out of order (introduced in 5.4.0)

[jkasten2]

Description

One Line Summary

Fix rare bugs with User and Subscription creates and updates processing out of order that was introduced in 5.4.0.

Details

Made a new internal coroutine scope with a single thread to the OperationRepo to ensure operations are alway executed in the order they are queued in.

This mostly fixes the flaky OperationRepoTest class.

Release 5.4.0 may have introduced bugs related to this, however they would have been rare and very hard to reproduce.

• Pre-5.4.0 there was also a rarer chance that usages of enqueueAndWait could have been out of order, it wasn't being put on the same scope as enqueue.

Motivation

The original motivation was to fix flaky OperationRepoTest tests, however the underlaying cause is that the OperationRepo sometimes processes operations out of order.

Scope

Only effects operation repo logic.

Testing

Unit testing

No new tests added, existing coverage already.

Manual testing

Tested on an Android 14 and Android 6 emulator, ensured a new User and Subscription gets created.

Affected code checklist

• Notifications
  • Display
  • Open
  • Push Processing
  • Confirm Deliveries
• Outcomes
• Sessions
• In-App Messaging
• REST API requests
• Public API changes

Checklist

Overview

• I have filled out all REQUIRED sections above
• PR does one thing
  • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
• Any Public API changes are explained in the PR details and conform to existing APIs

Testing

• I have included test coverage for these changes, or explained why they are not needed
• All automated tests pass, or I explained why that is not possible
• I have personally tested this on my device, or explained why that is not possible

Final pass

• Code is as readable as possible.
  • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
• I have reviewed this PR myself, ensuring it meets each checklist item
  • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

---

This change is 

[jinliu9508]

This fix is scoped to OperationRepo and doesn’t cover all usages of suspendifyOnIO (or, more broader OneSignalDispatcher). Because OperationRepo can be heavily used and is where this issue is most likely to surface, I’m in favor of merging this as a short-term, targeted fix and then following up with a broader dispatcher-level solution in a separate PR.