[Bug] Some pending properties can be sent to new user incorrectly, when users change

[nan-li]

Description

One Line Summary

Fixes bug that when users change, user updates like tags for the previous user can be sent incorrectly to the new user.

Details

This PR has two main changes:

1. OSDelta will now have an ID of the Identity Model it is meant for. Previously, user updates such as add tags and adding email / sms subscriptions did not have any reference to the Identity Model. As a result, when the OSDelta is processed into Requests to send to the server, we attach them to the current user. However, since the Operation Repo and Property Executor use a dispatch queue, the user may have switched by then.

2. Use a central repo to hold Identity Model instances that are being used during an app session. On subsequent cold starts, when Deltas and Requests are uncached, they will go through the repo to hook up the identity model instances so they are all operating on, and updating, the same instance. If their identity model does not exist yet, it will be added to the repo.

Motivation

Bug fix

Scope

• OSDelta has a new field containing the ID of the identity model it is meant for
• On the first cold start after the upgrade: The old OSDeltas will be dropped since they will be missing the Identity Model ID
  • It is unlikely for Deltas to still exist as we flush them into Requests when users change or app backgrounding
• Add a lightweight Identity Model Repo to manage instances that are still being used
  • An alternative considered is refactoring the Identity Model Store and would require it to basically override all of the OSModelStore methods
• Remove unused property: The Update User requests were holding on to a property model reference and this was unused and not needed, so it has been removed.

Testing

Unit testing

• Added test testSwitchUser_sendsCorrectTags [tests] Add test for switching users with adding tags
  • This test logs in userA, adds a tag, then logs in userB, adds a tag.
  • This test reproduced the behavior to fix, where both tags were sent to UserB.

Manual testing

iPhone 13 on iOS 17.4

Scenario 1:

1. Reproduced the bug by calling addTag() and immediately logging into another user. The tag went to the new user.
2. After this PR, the tag goes to the correct user.

Scenario 2:

1. Prerequisite: Already logged into an identified user, <user_a>
2. Call these methods in immediate succession
3. There are 3 users involved. Confirmed all data is sent to the correct user.

// Current user in SDK is <user_a>

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

[OneSignal login:<user_b>];
[OneSignal.User addAliasWithLabel:@"b" id:@"b"];
[OneSignal.User addTagWithKey:@"b" value:@"b"];
[OneSignal.User setLanguage:@"zh"];
[OneSignal.User addEmail:@"b@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. Same as Scenario 2, but those methods are now called on a new app install after initialization.
2. The SDK forms the requests correctly, and they are sent to the correct user.
3. However, a bug was found when anon -> login -> logout / login are called in succession. The middle user's data (who underwent Identify User) gets dropped. This bug is not related to the changes in this PR, so the fix will be in an upcoming PR.

// 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:<user_b>];
[OneSignal.User addAliasWithLabel:@"b" id:@"b"];
[OneSignal.User addTagWithKey:@"b" value:@"b"];
[OneSignal.User setLanguage:@"zh"];
[OneSignal.User addEmail:@"b@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 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:<user_a>];
[OneSignal.User addTagWithKey:@"a" value:@"a"];
[OneSignal login:<user_b>];

// No requests go through

3. Wait 30 seconds and kill app
4. Turn on wifi and reopen app
5. See requests uncache and models are connected through the Identity Model Repo
6. Requests go to the correct users but also suffers from the bug mentioned above.

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]

I pushed some changes for testing, reproducing the behavior in [tests] Add test for switching users with adding tags where the test fails before (both tags are sent to UserB), and passes after.

[nan-li]

Tests were failing because some state carried over, added more resets to the User Manager