[Improvement] avoid unnecessary user fetchs; on first app open and first login

[jkasten2]

Description

One Line Summary

Avoids unnecessary fetch user scenarios; 1. App open - first time. 2. Login - with a unique externalId, when user is anonymous.

Details

Case 1
UserRefreshService would always add a RefreshUserOperation to the OperationRepo on cold start. However this is not needed for the first time the app is opened, as there is no need to fetch a User we just created.

Case 2
If OneSignal.login() is called and the user is currently anonymous then we simply identify the User. If identifying is successful then there is no need to fetch the user, as its the same user, we just added an Aliases to them.

Motivation

Preventing unneeded networks calls optimizes both device and OneSignal backend resources.

Scope

Only affects fetch User.

Related

Related fetch user changes were recently made in [Improvement] limit refresh User and GET IAMs to foreground #2036

Testing

Unit testing

Added a new Unit test for Login executor

Manual testing

Tested on an Android 14 emulator:

1. Fresh install, ensured we don't make an unneeded fetch user
2. Cold start the app after 1 above, ensuring it does make a user fetch
3. Fresh install, ensure calling login doesn't fetch the User if is a unique externalId
4. Fresh install, ensure calling login fetches we called create 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
  • 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 

[jinliu9508]

LGTM!!