WIP - Start a new session on a new app install

[nan-li]

WIP - whether or not to do this

Description

One Line Summary

REQUIRED - Very short description that summaries the changes in this PR.

Details

Background:
Each session has an isValid property that is read at the start of a potential new session. If this value read is false, then a new session will start and its property is set to true. If this value read is true, that means we continue on this same previous session.
At the end of the session, this property will be set to false.

Problem:
On a brand new app install, we were defaulting this value to true, which means the logic to trigger a new session will not happen, since the SDK will believe it should continue from a previous session. However, this is the first time the app is opened after a new install.

Solution:
By defaulting instead to false, we ensure that this first app open will start a new session. In addition, this will trigger a TRACK_SESSION_START operation and ask the server to refresh_device_metadata, updating country and IP for this user.

Sending this request body:

{
	"refresh_device_metadata":true,
	"deltas":{"session_count":1}
}

This is in line with what the iOS SDK does on a new app install as well.

Motivation

The primary motivation is to send a request to update country and IP after creating a user on a new app install. Secondary motivation is starting off the very first session correctly.

Scope

Affects the very first session on a new app install.

Testing

Unit testing

None

Manual testing

Tested on Android emulator API 33

1. new app install
2. the user creation succeed
3. a subsequent update user request is sent with {"refresh_device_metadata":true, "deltas":{"session_count":1}}
4. User in dashboard has country and IP
5. Background app for > 60 seconds
6. Open app, new session starts (same behavior as before)
7. Background app for < 30 seconds
8. Open app, continues on same session (same behavior as before)

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]

See instead #1932