RUMM-1615 Allow launch time earlier than UIApplicationDidBecomeActiveNotification

[maxep]

What and why?

This PR is a proposal on allowing sending the application_start action with a loading_time value before the application has become active.

The SDK measures the Application launch time from the time the application process starts until when it is responsive and accepts touch events. This is performed by responding to UIApplicationDidBecomeActiveNotification.

In case the RUM monitor receives the first startView command before the application has become active, the application_start action event is recorded without a loading_time. This will be the case when invoking startView manually from the UIViewController.viewWillAppear or from SwiftUI.View.onAppear for instance.

In this proposal, we make sure to always return a Launch Time when requested, by either returning the time to become active (as before) or the time to receive the first startView command.

How?

The __dd_private_AppLaunchTime function now returns the time from start until 'now' if the UIApplicationDidBecomeActiveNotification has not yet been received.
To reflect this change, the LaunchTimeProviderType now expect a non-optional launchTime.

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)
• Make sure each commit and the PR mention the Issue number or JIRA reference

[maxep]

In terms of testing, I could apply a change in RUMManualInstrumentationScenarioTests to cover this use case, but I would rather wait for covering it in the up coming SwiftUI tests, WDYT?

[ncreated]

There are two things I'm concerned about:

• The new "lazy" aspect of .launchTime API makes it slightly dangerous. It's easy to imagine introducing a bug by calling it somewhere earlier in the stack which will skew the measurement. Seems hard to cover this in tests.
• Using launchTimeProvider.launchTime to stop measurement in RUMViewScope skews the real measurement by the time of queue.async {} used to run RUM "start view" command.

What's our take on the above? Is there any alternative we can consider 🤔 💭?

[maxep]

The new "lazy" aspect of .launchTime API makes it slightly dangerous.

The launchTime property is not lazy but computed, calling it earlier in the stack won't stop measuring the UIApplicationDidBecomeActiveNotification. It's applying a fallback in case the UIApplicationDidBecomeActiveNotification has not yet been reached.

Though, It is true that UIApplicationDidBecomeActiveNotification could be triggered by the time it reaches queue.async { }, even if queue has a .userInteractive qos, it's part of another scope.

Another approach would be to respond to the following notifications:

• UIWindowDidBecomeVisibleNotification
• UIApplicationDidFinishLaunchingNotification
• UIApplicationDidBecomeActiveNotification

And then report the last notification received 🤔

[ncreated]

Another approach would be to respond to the following notifications (...)

Or we could add our own notification, sent from RUMMonitor.startView(), but this sounds like adding cruft...

The launchTime property is not lazy but computed (...). It's applying a fallback

I totally missed that .launchTime is computed now. This mitigates the first point on my list 👍.

Maybe the queue.async {} impact is not that significant as it will be uniformly added to all measurements for the same scenario. @maxep @buranmert ?

[maxep]

Yes, I don't think the async process will have an impact on the reported time. IMO, this is the minimal change we can apply and it preserve from regressions.