Detect for timezone changes and update the user

[nan-li]

Description

One Line Summary

Send up timezone ID as a one-time migration, send up timezone ID when fetching the legacy player, and start detecting timezone changes and sending it up when it changes.

Details

• Unless users switch via logging in and out, we never update timezone (as it is only sent in the Create User request).
• Now, we cache timezone ID and detect for changes on cold starts and update the user when it changes.
• We also fix a rare issue that comes from upgrading from a very very old version of player model to user model. When we have a legacy player ID, we fetch its identity rather than creating a user. In some rare cases, this old player is already missing a timezone (version used was before we added timezone collection to the player model SDK), and the SDK never calls Create User to set a timezone. As a result, this user will be missing timezone.
• As a one-time migration, we send up the timezone in the next release for all users without considering if timezone is indeed missing or not. Note that this update will be combined in the payload of the session_count update. This update is driven by reading the timezone_id from cache, but before this PR, timezone was never cached, so it will return null, driving this one-time update.

Motivation

Reports by customers about missing timezones on very old players after migrating to v5.
Also requests by customers to detect timezone changes.

Scope

Sending timezone

Testing

Unit testing

None added

Manual testing

iPhone 13 on iOS 18.1
Scenario tested - player model upgrade:

1. Upgrade from an existing player model installation
2. SDK uncaches the legacy player, fetch the identity, and sends the timezone
3. Next cold start, no timezone is sent when there is no change
4. Change timezone on phone and make a cold start
5. The new timezone is sent

Scenario tested - user model upgrade:

1. New install on main
2. Upgrade to this branch
3. See that timezone is sent up in a one-time migration. There may have been old players who were missing timezone, upgraded to user model, and still missing timezone.
4. Subsequently, no timezone is sent when there are no changes
5. If timezone does change on phone, it is sent up.

Scenario tested - new install:

1. New installs call Create User so timezone is sent, same as before.
2. Now moving forward, when it changes on the device, it is sent.

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]

Test OneSignalNotificationsTests.testDontclearBadgesWhenAppBecomesActive() has always been flaky.