Fix ANR caused by operationRepo.enqueue while loading is in progress

[jinliu9508]

Description

One Line Summary

This PR will fix ANR caused by model store insertion while model store loading is stuck with some prolonged process.

Details

Motivation

Multiple users have reported that ANRs related to OneSignal have shown up in their analytics. We want to eliminate these ANRs to ensure smooth app start up.

Scope

This PR introduces a new object OSPrimaryCoroutineScope that can be used to run any task in a designated coroutine scope. We can assign a certain tasks that can be potentially blocked to run under this primary coroutine scope instead of the main thread so we don't block the main thread if the task can be blocked by other processes like loading from the disk. The PR specifically changes the enqueue calls in SessionListener and UserRefreshService because they can be called immediately after app startup.

Others

This PR contains 4 commits.

• The 1st commit forces a prolonged loading process for OperationModelStore and will cause an ANR during app startup.
• The 2nd commit adds a test unit that will fail because of the long loading time added by the first commit.
• The 3rd commit applies the fix and we should no longer observe the ANR and the test fail.
• The 4th commit clears up the code that manually forces the loading process to take 5 seconds.

Testing

Unit testing

I have included a test unit to simulate a model insertion while loading is blocked by a lengthy process.

Manual testing

The first commit manually force the loading of operationRepo to take at least 5 seconds in order to simulate the issue. By checking out the first commit and run the demo app, we can observe an ANR on app startup. Once we check out the third commit which contains the fix, we can no longer reproduce the ANR.

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