fix: Prevent overwriting with fallbacks when updating endpoint

[cshfang]

Description of changes

When calling initializePushNotifications, the library calls an internal updateEndpoint API. Anytime updateEndpoint is called, it automatically populates the demographic property with client info and the userId with the identity id. When calling identifyUser, these values can be provided explicitly but will always be pre-populated. This can have unexpected consequences since initializePushNotifications is typically called on every app launch - and it will opaquely overwrite existing values previously set on the endpoint.

This PR updates the updateEndpoint API to only pre-populate these fields when creating an endpoint to avoid repeatedly overwriting the endpoint with the default/fallback values.

Issue #, if available

#13174

Description of how you validated changes

• yarn test
• Added unit tests that were expected to fail prior to code changes and verified they are now passing
• Tested on sample app to see that demographic and userId are only on the network request when an endpoint has yet to be cached (endpoint creation) and subsequent calls do not.

// Endpoint creation
{
  "RequestId": "8808844f-5e12-440b-a914-d3ae7191b0f8",
  "EffectiveDate": "2024-05-02T19:55:22.795Z",
  "ChannelType": "APNS_SANDBOX",
  "Address": "<apns-token>",
  "Demographic": {
    "AppVersion": "ios/17.0",
    "Make": null,
    "Model": null,
    "ModelVersion": "17.0",
    "Platform": "ios"
  },
  "User": { "UserId": "<cognito-identity-id>" }
}

// Endpoint update
{
  "RequestId": "8178652f-5842-44b6-a02c-27616f4d6cb9",
  "EffectiveDate": "2024-05-02T19:57:28.751Z",
  "ChannelType": "APNS_SANDBOX",
  "Address": "<apns-token>",
}

Checklist

• PR description included
• yarn test passes
• Tests are changed or added

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[erinleigh90]

Thanks, Chris! Good catch.

Had one nit and one question but LGTM!

[erinleigh90]

Nit: Did we decide that || is better to use than ??

Suggested change

	const resolvedUserId = createdEndpointId ? userId ?? identityId : userId;
	const resolvedUserId = createdEndpointId ? userId || identityId : userId;

[erinleigh90]

To make sure I understand: the identityId property is always a default value and userId is always customer provided or empty, correct?

[cshfang]

If this call creates an endpoint

• use userId if provided, otherwise fall back to identityId

If this call updates an endpoint

• use userId if provided but don't fall back to anything

To make sure I understand: the identityId property is always a default value and userId is always customer provided or empty, correct?

identityId is always only a default/fallback value but is only set during endpoint creation. userId is always customer provided or empty, yes.

Nit: Did we decide that || is better to use than ??

Generally speaking, ?? is almost always what we intend unless we explicitly want falsy values like 0 or '' to qualify as "empty"