[Fix] Handle incorrect `404`, delay making requests to new IDs

[nan-li]

Description

One Line Summary

Handle incorrect 404 responses from the OneSignal's backend by adding a delay after creates, when new subscription IDs or OneSignal IDs can be created on the backend.

Details

See Android Implementation here

Backend Issue

OneSignal sometimes returns a 404 on GET and PATCH requests if you are accessing something immediately after it was created. Normally the OneSignal backend can accept fetch/updates right way, but it all depends on it's server load and replication process. There isn't a guaranteed amount of time a client can wait, so SDKs has to work around this problem.

SDK's work around strategy

Add a minimum delay after creating records (User or Subscription) before allowing any requests to fetch or update that specific record, based on the onesignalId or subscriptionId.

• We picked 3 seconds as this "cool down" period. This is a best guess, we are balancing SDK responsiveness with the chance of running into this issue, as well as timing for Operation Repo's 5 second flush interval.
• Also noting that backend team said "it looks like we can have peaks of up to 300ms for database replication lag. If you added 0.5s delay between each network request, that would likely resolve some of these issues"

Motivation

404/410 responses are being handled by recreating the missing record (User or Subscription), however this isn't always the right way to handle these, give the backend caveat noted above. Recreating these records can create side-effects and extra load we want to avoid.

Scope

Add a delay processing user-based or subscription-based requests.

Future Considerations

• We want to refactor Operation Repo and Executors relationship down the line, so this PR is minimal to prevent the primary errors. The 3 second delay should be sufficient to address the overwhelming majority of incorrect 404 cases, especially as backend team mentioned a delay of 0.5 seconds should be sufficient.
• As the 404/410 may still happen when the backend is under unusual load (a 3 second delay may not always be enough) we can also retry on 404/410 within a longer but still short window.
• Calls that do not go through the Operation Repo and Executors could have this same logic applied.
  • Live Activities requests, Fetch IAM, and Outcomes requests.
• The new parameter for the delay interval could be read from remote params, so it can be tweaked later.

Testing

Unit testing

🚧 New unit tests are WIP

Manual testing

Physical iPhone 13 on iOS 17.4

• New install
• New install with immediate login to new user
• New install with immediate login to existing user

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 

[nan-li]

Badge test started failing this week, but can look at later.

It looks like the runner-image has changed, and the new tests are run on ios 18.1.

Previous passing runner image used:

Included Software: https://github.com/actions/runner-images/blob/macos-14/20240811.3/images/macos/macos-14-Readme.md Image Release: https://github.com/actions/runner-images/releases/tag/macos-14%2F20240811.3

Failing runner image used:

Included Software: https://github.com/actions/runner-images/blob/macos-14/20240818.2/images/macos/macos-14-Readme.md Image Release: https://github.com/actions/runner-images/releases/tag/macos-14%2F20240818.2