[Bug] Fix processing of Identify User response if the user has changed since then

[nan-li]

Description

One Line Summary

Fix processing of Identify User response when the user has changed since, so that pending updates will still be sent and transfer subscription happens only in correct situations.

Details

Note that this bug only manifests if multiple logins to different users are called one after another, or the requests are not able to succeed (server is down, or there is no internet connection during which time multiple logins are called). This PR tests and addresses those scenarios.

Motivation

Consider the scenario Anon -> Login User A (Identify User) -> Login User B (Create User)

• Dropping user updates
  • When the Identify User request returns, because the user is now different, we were not fetching User A to hydrate the OSID, so any updates made to it get dropped. Now, we mark the Identity Model to use the external_id for pending requests.
• Transferring push subscription incorrectly
  • In addition, transfer subscription had a bug. Create User B already contains the push subscription in the payload, but when Identify User A returns, we still enqueue a Transfer Subscription to User A request, which would create this flow: Anon -> Login User A (Identify User) -> Login User B (Create User) -> Transfer Subscription to User A
  • Now we only transfer if it's still the same user. Any Create User requests would already have the push subscription in it.
  • This was a recoverable bug as the next Fetch User B call would find the push subscription gone, and the SDK would call Create Subscription for User B with the push subscription data.

This PR also fixes the bugs mentioned under Manual Testing section for #1418

User State Change Observer

⚠️ The User Observer was never triggered for the 409'd middle user. That is still the case after this PR, as we never hydrate its onesignal_id.

Scope

• Main logic change is in commit [Bug] Fix Identify User processing if the user has changed and Avoid a fetch user after login returns 409
• Other changes are tests-related

Testing

Unit testing

• Changes to mock client to process requests asynchronously
• Add test to reproduce behavior in [tests] Add test to reproduce Identify User when in middle bug which fails prior to the fix

Manual testing

Tested on iPhone 13 with iOS 17.4

✅ Scenario 1:

1. On new app install after initialization, immediately call these methods.
2. Confirm tags are sent to <some_existing_euid> by way of external_id

// New App Install

[OneSignal initialize:<app_id> withLaunchOptions:launchOptions];

[OneSignal login:<some_existing_euid>]; // returns 409
[OneSignal.User addTagWithKey:@"a" value:@"a"];
[OneSignal login:<user_b>];

✅ Scenario 2:

1. On new app install after initialization, immediately call these methods.
2. Confirm every update is sent and is sent to the correct user.

// New App Install

[OneSignal initialize:<app_id> withLaunchOptions:launchOptions];

[OneSignal.User addTagWithKey:@"a" value:@"a"];
[OneSignal.User setLanguage:@"fr"];
[OneSignal.User addAliasWithLabel:@"a" id:@"a"];
[OneSignal.User addEmail:@"a@example.com"];

[OneSignal login:<some_existing_euid>];
[OneSignal.User addAliasWithLabel:@"existing" id:@"existing"];
[OneSignal.User addTagWithKey:@"existing" value:@"existing"];
[OneSignal.User setLanguage:@"zh"];
[OneSignal.User addEmail:@"existing@example.com"];

[OneSignal logout];
[OneSignal.User addTagWithKey:@"c" value:@"c"];
[OneSignal.User setLanguage:@"es"];
[OneSignal.User addEmail:@"c@example.com"];
[OneSignal.User addAliasWithLabel:@"anonymous" id:@"anonymous"];

✅ Scenario 3:

1. Check everything is correct when the current user is still the same as the Identified User (no regression).
2. On new app install after initialization, immediately call these methods.
3. Confirm every update is sent and is sent to the correct user.
4. The user in the SDK is correctly hydrated.

// New App Install

[OneSignal initialize:<app_id> withLaunchOptions:launchOptions];

[OneSignal.User addTagWithKey:@"a" value:@"a"];
[OneSignal.User setLanguage:@"fr"];
[OneSignal.User addAliasWithLabel:@"a" id:@"a"];
[OneSignal.User addEmail:@"a@example.com"];

[OneSignal login:<some_existing_euid>];
[OneSignal.User addAliasWithLabel:@"existing" id:@"existing"];
[OneSignal.User addTagWithKey:@"existing" value:@"existing"];
[OneSignal.User setLanguage:@"zh"];
[OneSignal.User addEmail:@"existing@example.com"];

// Don't logout or login to another user

✅ Scenario 4:

1. Turn off wifi and data (no network connection)
2. New app install and call the following methods

// New App Install

[OneSignal initialize:<app_id> withLaunchOptions:launchOptions];
[OneSignal login:<some_existing_euid>];
[OneSignal.User addTagWithKey:@"a" value:@"a"];
[OneSignal login:<user_b>];

// No requests go through

5. Wait 30 seconds and kill app
6. Turn on wifi and reopen app
7. Requests go to the correct users.

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 - none

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]

Followup PR #1430 testing user switching is also testing these changes.

Note CodeQL is broken after push to start live activities merged to main, its autobuild action no longer works.