* Properties on the push subscription can change between app opens such as app version, SDK version, or device OS
* These changes aren't driven by changes in the SDK and previously wouldn't be detected as changed
* Now, on each new session, we will ask the push subscription model to check itself for updates and enqueue those changes.

- Create the push sub model with the notification_types at time of creation
- This is so that on the first app open, we can receive push prompt IAMs (server expects to have an appropriate notification_type to determine eligibility)

* On a new session, we fetch the user. If we detect our push subscription missing from the user (indicating the push subscription may be deleted), we send a create subscription request for the device's push sub.

* On the user manager
* We access the push subscription model via the model store instead of via `user.pushSubscriptionModel`.
* If privacy consent is set in a wrong order, we may have sent requests, but hydrate on a mock user.
* However, we want to set tokens and subscription ID on the actual push subscription model.

* If a createUser fails, let's pause the operation repo. We will still poll, but we won't flush it is paused.
* After a create user request is uncached, update the `originalPushToken` property to be the push token associated with this request. Because, we update the push subscription before sending this request.

* On a new session, we will trigger the user executor to execute any pending requests, in case there is a failed create user request that should be retried. We can't rely on the operation repo flushing to trigger the user executor as it bypasses the operation repo.

* Use the existing `isCurrentUser` method
* remove extraneous logging that make the logs messy

Cherry pick #1276

The JS dismiss event is being sent to the SDK twice. Make sure we don't dismiss twice or the second IAM in the queue will be dismissed before it is displayed

* Each executor manages its own background task
* For attributed sessions, define another background task to send the session_time to update user (in addition to the existing request to the outcomes endpoint)

* When app is backgrounded, flush the operation repo and let each executor and request manage its background task
* don't end background tasks until requests return
* Processing the queues will take in another flag called `inBackground`

* Add callbacks before ending the background task to send attributed session time, and save unsent time as zero only after a success callback
* This waits 30 seconds in the background

* When app is backgrounded, create a background task and send the session_time to the user endpoint
* Have callbacks, bypassing the operation repo
* This is done both for unattributed sessions that send the request right away and for attributed sessions that wait 30 seconds before sending

* Remove messy logging
* Add informational log for background task expiring

* When we set tags and it goes over limit, we don't delete them locally.
* Let's do the same for added aliases that can't be added to the user due to conflict
* The SDK will refresh itself on new sessions
* We will need better systematic way to address these types of failure cases

[5.0.0] Fix background tasks

[User model] Fix in app display

[5.0.0] Allow the SDK the chance to recover from failed Create User

* Rename `OSBackgroundTaskManagerDelegate` -> `OSBackgroundTaskHandler` because it is not truly a delegate, but is a concrete implementation that is injected