Update push subscription model properties between sessions

[nan-li]

Description

One Line Summary

On new sessions, we will update the server with changes to app version, sdk version, carrier, and device OS.

Details

Motivation

If app version or sdk version is updated, these updates should be sent to the server.

Scope

1. Add these properties to Subscription Model
First, these properties should exist on Subscription Model. It now has sdk, deviceOS, carrier, and appVersion as properties so that they can persist. When push subscription models are initialized, these properties are now also set on the model.

2. On new sessions, check for subscription property updates
Let the SubscriptionManager refresh the push subscription model on new sessions.

3. Don't hydrate this info for a push subscription model
When hydrating an existing push subscription model, use existing local data for these properties.
This information should always come from the local device. The reason for this change is that on a new session, we may detect a change to one of these properties and we do not want to overwrite it with old remote data from the get_user response.

There are other ways to implement this PR, and open to discussing another approach.

Testing

Unit testing

None, should consider adding a test that can test this.

Manual testing

Android 33 Emulator

• Tested new app installs
• Tested with logging in
• Tested an existing app installation that does not have this data saved, and then running a new session with the changes in this PR. It will enqueue extraneous update subscription operations because it had no previous data to compare, but this is acceptable as the SDK is on a new version anyway. Eventually, there will be a single update request sent with a snapshot of the push subscription model.

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 

[emawby]

Reviewed 8 of 8 files at r1, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @jennantilla, @jinliu9508, @jkasten2, @nan-li, and @shepherd-l)