[Fix] Don't re-create user on failed remove alias

[jkasten2]

Description

One Line Summary

If a removeAlais failed due to a 404 or 410 we incorrectly assumed it was due to the User being deleted, causing it be re-created in a loop.

Details

How the bug is triggered

This fixes a bug where the OperationRepo gets stuck in a loop trying to create the user over-and-over again, if OneSignal's backend returned a 404 or 410 when the alias remove was attempted. This can be triggered in these two ways:

1. Multiple deletes for the same alias get into the queue. Can happen if you call addAlias("labelA", "idA"); removeAlias("labelA"); addAlias("labelA", "idA"); removeAlias("labelA") back-to-back.
   • This PR doesn't fix two deletes getting into the queue, or preventing them from executing. Preventing the attempted network call that we know will fail or do nothing is larger issue than just aliases.
2. If something outside the SDK removes the Alias, then it's attempted by the SDK.

Internal details

We incorrectly assumed that getting a 404 or a 410 from DELETE users/by/$aliasLabel/$aliasValue/identity/$aliasLabelToDelete means the user is gone. It could mean either the User and/or the Alias is gone, either way the end state is the same, the alias no longer exists on that User. If the User was really deleted we will know on the next User operation, and that will handle the create User.

Effect on OneSignal's backend

Only apps that used OneSignal.User.deleteAlias(), in specific scenarios noted above.

• 5.1.7 & 5.1.8 - With the current SDK logic, retrying was be done with a backoff, so retrying won't have had much of an impact on the OneSignal's backend load
• 5.0.0 - 5.1.6 - In the lower number of apps using deleteAlias and the rare conditions need to hit this it would have created a storm of POST /users and GET /users calls, along with DELETE users/by/$aliasLabel/$aliasValue/identity/$aliasLabelToDelete calls.

Motivation

Re-creating the user when it isn't needed can create many side-effects we want to avoid.

Scope

Only affects OneSignal.User.deleteAlias()

Testing

Manual testing

Tested on an Android 14 emulator with the example app calling the following code just after initWithContext.

OneSignal.getUser().addAlias("labelA", "idA");
OneSignal.getUser().removeAlias("labelA");
OneSignal.getUser().addAlias("labelA", "idA");
OneSignal.getUser().removeAlias("labelA");

Ensured it no longer tries to create a new User over and over in a loop.

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