[Feat] Use only OneSignal ID for requests

[nan-li]

Description

One Line Summary

Use only OneSignal ID for requests, no longer using any External ID for requests.

Details

• Fetch user will only occur with OneSignal ID, no more EUID
• Any user updates will only occur with OneSignal ID, no more EUID
• Remove Transfer Subscription Request except to uncache on upgrade only
  • Still relevant Transfer Subscription request will be converted into an equivalent Create User request
  • Cached Transfer Subscription requests should be rare - in order for this to be cached, it means the Identify User request returned 409 but the immediate Transfer Subscription did not send or resulted in a retry-able error response
• Identify User success and conflict responses result in different behavior now
  • Both will call Create User instead of marking pending requests to use EUID or fetching and transferring the push subscription

Motivation

Move away from using External ID in request URLs, only using OneSignal ID.

Scope

Making requests

Testing

Unit testing

• No new unit test are added, but existing unit tests are updated

Manual testing

Device: iPhone 13 on iOS 17.5.1

Identify User with success (external ID applied successfully)

1. Start with anonymous user in the SDK 2. Add a tag and an email 3. Login to a new user (brand new external ID) 4. The Identify User request is successful 5. Fetch User by OSID happens 6. Local state is correct and contains the tag and email

Identify User with 409 conflict

1. Start with anonymous user and login to an existing EUID 2. Receive 409 conflict response 3. If the user is the current user, it will make a CreateUser request with the external ID and push subscription in the payload 4. If the user is now different, it will make a CreateUser request with the external ID only for hydration of the OneSignal ID, for any pending requests for that previous user

SDK Upgrade: There is a cached Transfer Subscription for the current user

1. Reproduce this on `main` by login to an existing EUID 2. The Identify User happens and receives 409 conflict response 3. The subsequent Fetch User by EUID and Transfer Subscription are generated and cached, but do not get sent 4. Upgrade SDK to this version 5. During uncaching, the Fetch User is dropped and the Transfer Subscription is converted to a CreateUser containing the external ID and push subscription. 6. User observer fires and everything looks correct.

SDK Upgrade: There is a cached Transfer Subscription for a previous user

1. Reproduce this on `main` by login to an existing EUID `userA` 2. The Identify User happens and receives 409 conflict response 3. The subsequent Fetch User by EUID and Transfer Subscription are generated and cached, but do not get sent 4. Now login to another user `userB`, which enqueues a CreateUser request 5. Upgrade SDK to this version 6. During uncaching, the Fetch User is dropped and the Transfer Subscription is dropped, only the CreateUser remains 7. The CreateUser is sent and the state in the SDK seems correct for `userB`.

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