RUM-11784: Send TTID vital

[aleksandr-gringauz]

What does this PR do?

This PR implements sending of TTID value using Rum VitalEvent with ApplicationLaunchProperties. Merging into a feature branch for now.

Motivation

What inspired you to submit this pull request?

Additional Notes

Anything else we should know when reviewing?

Review checklist (to be filled by reviewers)

• Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
• Make sure you discussed the feature or bugfix with the maintaining team in an Issue
• Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

[datadog-datadog-prod-us1]

🎯 Code Coverage
• Patch Coverage: 98.85%
• Total Coverage: 70.84% (-0.05%)

View detailed report

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: fcd356b | Docs | Was this helpful? Give us feedback!}

[codecov-commenter]

Codecov Report

❌ Patch coverage is 96.49123% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 71.08%. Comparing base (641c42d) to head (fcd356b).
⚠️ Report is 2 commits behind head on aleksandr-gringauz/feature/app-launch-vitals.

Files with missing lines	Patch %	Lines
...d/rum/internal/domain/scope/RumVitalEventHelper.kt	93.33%	1 Missing and 4 partials ⚠️
...lin/com/datadog/android/rum/internal/RumFeature.kt	0.00%	1 Missing ⚠️

Additional details and impacted files

@@                               Coverage Diff                                @@
##           aleksandr-gringauz/feature/app-launch-vitals    #2944      +/-   ##
================================================================================
+ Coverage                                         71.02%   71.08%   +0.06%     
================================================================================
  Files                                               829      830       +1     
  Lines                                             30381    30447      +66     
  Branches                                           5183     5186       +3     
================================================================================
+ Hits                                              21578    21642      +64     
- Misses                                             7347     7356       +9     
+ Partials                                           1456     1449       -7     

Files with missing lines	Coverage Δ
...rum/src/main/kotlin/com/datadog/android/rum/Rum.kt	90.00% <100.00%> (+0.94%)	⬆️
...d/rum/internal/domain/scope/RumApplicationScope.kt	95.24% <100.00%> (+0.12%)	⬆️
...g/android/rum/internal/domain/scope/RumEventExt.kt	95.25% <100.00%> (+1.18%)	⬆️
...droid/rum/internal/domain/scope/RumSessionScope.kt	95.81% <100.00%> (+0.92%)	⬆️
...d/rum/internal/domain/scope/RumViewManagerScope.kt	93.55% <100.00%> (+0.52%)	⬆️
.../android/rum/internal/domain/scope/RumViewScope.kt	94.26% <100.00%> (+0.17%)	⬆️
.../android/rum/internal/monitor/DatadogRumMonitor.kt	90.05% <100.00%> (+0.03%)	⬆️
...roid/rum/internal/startup/RumAppStartupDetector.kt	100.00% <100.00%> (ø)
.../rum/internal/startup/RumAppStartupDetectorImpl.kt	95.74% <100.00%> (ø)
...android/rum/internal/startup/RumStartupScenario.kt	100.00% <100.00%> (ø)
... and 2 more

... and 17 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[0xnm]

I'm not sure if we need to set this flag at all here. Yes, there is such property, but it is only app start, so no real view yet, hence nothing to replay. We have view = null above anyway. WDYT?

If we don't set this property, we even simplify the code, because there is not need to pass FeaturesContextResolver around.

[aleksandr-gringauz]

Good question, I'm not sure either.

Let's consider the situation when the customer uses ActivityViewTrackingStrategy.

1. The view starts in onResume.
2. The first draw (and TTID Vital event as a result) will happen slightly (less than a second) after this, so technically the view already exists.
3. The "has_replay" flag for a view that we check here is set here. This happens when a session replay event is recoded here.
4. In practice I've never seen hasReplay = true in my implementation. As far as I understood the session replay event isn't written fast enough. However if you delay the TTID for 5 seconds hasReplay will be true. We have a race here.
5. To wrap up. In practice this hasReplay in my case is kind of useless and will in most cases be false. I can just pass hasReplay = null, I don't think it will be a problem.

[0xnm]

I think having hasReplay = null here is fine. This property is just a sticky flag which is reduced over view updates and pulled to the session level. So basically once it is set, it means that the given session has Session Replay. It means that if any other view (presumably the real one) update delivers it, this will be fine.

[aleksandr-gringauz]

changed to hasReplay = null and simplified the code.