[v5] Pause operation repo and retry failed user create

[nan-li]

Description

One Line Summary

Give the SDK a future chance to recover from failed user creation, similar to the behavior of the iOS SDK.

Details

Successful user creation is vital to the functioning of the SDK.

Problem:
If the create user request fails with an un-retryable error such as a 400 response, the SDK would not retry and stay in an unrecoverable error state with no onesignal_id, and no subscription_id (potentially). Therefore, it would never register, send data, or receive notifications. The only way out was to uninstall the app.

Solution:
Let's give the SDK a chance to recover from failed user creation, similar to the behavior of the iOS SDK. When met with this error, we will pause the operation repo from executing any more operations as it is impossible to do anything without a onesignal_id.

Then, on new sessions or new cold starts, we will retry the still-cached operation, in the hopes that perhaps it can succeed at this later date.

Motivation

If the create user request fails with an un-retryable error such as a 400 response, the SDK would not retry and stay in an unrecoverable error state with no onesignal_id, and no subscription_id (potentially).

Scope

Only affects user create requests that receive a 400-range error.

Testing

Unit testing

None, but can consider adding in the future to mimic the behavior

Manual testing

Android emulator API 33

1. New app install with an unsupported device language (sl at time of testing)
2. Create User fails with 400 error
3. See the operation repo is paused
4. Call login to an existing EUID
5. Kill app and change device language to en
6. Re-open app a while later
7. Create User succeeds
8. Login also succeeds
9. The SDK is now logged into the appropriate EUID/user from the Login call.
10. Send and receive a push notification on the device

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
• 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.
• I have reviewed this PR myself, ensuring it meets each checklist item

---

This change is 

[jkasten2]

Would be nice to retry when there is change, instead of pausing and needing to restart the app. However that would be a pretty large refractor, so I think this is a good fix for now.