Remove early return of trackReceivedEvent to allow for os_notification_influence_open event to be sent to Firebase

[jennantilla]

Description

One Line Summary

Remove early return of trackReceivedEvent method to allow for the os_notification_influence_open event to be sent to Firebase.

Details

Motivation

The os_notification_influence_open event is not currently logged in Firebase. While initially thought to be an issue with the trackInfluenceOpenEvent method logic, it was eventually determined that the previous method,trackReceivedEvent, returned early and prevented the influence event from being sent.

Other

Since iOS does not support this os_notification_received event, the logEventWithName method for this event was also removed.

Our documentation currently states that the os_notification_influence_open event will be sent if the app is opened within two minutes of receiving a notification. This was originally thought to be the flawed logic preventing the event from being sent altogether. However, after updating the trackReceivedEvent method, the original logic works. However, if we determine to change the duration, that can be easily updated.

Testing

Unit testing

No unit testing was used.

Manual testing

Tested on an iPad running iOS 15.2.

Test Scenarios:

1. Tested opening the app within 2 minutes of receiving a notification. Confirmed in Firebase DebugView that the os_notification_influence_open event was successfully logged:

2. Tested opening the app after 2 minutes of receiving a notification and confirmed that no os_notification_influence_open event was logged in Firebase DebugView.

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
  • If it is hard to explain how any codes changes are related to each other then it most likely needs to be more than one PR
• 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.
  • Simplify with less code, followed by splitting up code into well named functions and variables, followed by adding comments to the code.
• I have reviewed this PR myself, ensuring it meets each checklist item
  • WIP (Work In Progress) is ok, but explain what is still in progress and what you would like feedback on. Start the PR title with "WIP" to indicate this.

---

This change is 

[jennantilla]

@jkasten2 / @emawby -- there were some interesting discoveries regarding this issue (see 'Other' section above). I've kept the original 2 minutes for influence opens to reflect the documentation, but can easily update this if there is another duration we'd like to use instead.

Thanks!

[nan-li]

LGTM, but let's see about if we want to change the Firebase influenced attribution time from 2 minutes.

[emawby]

Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @jkasten2 and @shepherd-l)

[emawby]

We should take it on as a separate fix to make the firebase influences match OneSignal influences (remove 2 minute logic)