RUM-699 fix: RUM context not being linked to started span

[ncreated]

What and why?

🐞 Fixes the bug of RUM information not being linked correctly on tracer.startSpan().

How?

The problem was introduced in V2 where we started sending RUM information in DatadogContext by propagating its updates on message bus. Because message bus adds one more asynchronous call, the information was not available in to tracer at the right time:

rumMonitor.startView(key: "view", name: "FooView")
let span = tracer.startSpan(operationName: "span") // <--- here, we haven't yet 
                                                   // seen Foo's `view.id` in `DatadogContext`
// ...
span.finish()

Under the hood, the propagation model was this:

• (in RUM) set RUM info in DatadogContext (async on context queue)
• (in Core) broadcast DatadogContext update to all modules (async on message bus queue)
• (in Trace) receive DatadogContext and store RUM info in MessageReceiver
• (in Trace) on starting span: capture received RUM info from MessageReceiver
• (in Trace) on finishing span: create & write span (async on context queue)

It is now simplified and changed to:

• (in RUM) set RUM info in DatadogContext (async on context queue)
• (in Trace) on starting span: capture latest DatadogContext (async on context queue)
• (in Trace) on finishing span: create & write span with DatadogContext captured on starting it (async on context queue)

Ultimately, RUM context is no longer passed to Trace through message bus and MessageReceiver. Instead, it is queried by DatadogTrace with the new capability added to FeatureScope:

public protocol FeatureScope {
    /// Retrieve the core context.
    ///
    /// A feature can use this method to request the Datadog context valid at the moment of the call.
    ///
    /// - Parameter block: The block to execute; it is called on the context queue.
    func context(_ block: @escaping (DatadogContext) -> Void)

    // ...
}

🎁 Part of the requirement to enable this work was removing tracer.queue and replacing it with @ReadWriteLock to synchronise tracer and span states. According to my benchmark measures, there is no performance change coming from this PR (both in Tracer and in DatadogCore).

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
• Add CHANGELOG entry for user facing changes

Custom CI job configuration (optional)

• Run unit tests for Core, RUM, Trace, Logs, CR and WVT
• Run unit tests for Session Replay
• Run integration tests
• Run smoke tests
• Run tests for tools/

[datadog-datadog-prod-us1]

Datadog Report

Branch report: ncreated/RUM-699/fix-rum-context-not-associating-with-spans
Commit report: 2ecfae1
Test service: dd-sdk-ios

✅ 0 Failed, 2739 Passed, 0 Skipped, 12m 40.75s Wall Time
🔻 Test Sessions change in coverage: 9 decreased, 5 increased

🔻 Code Coverage Decreases vs Default Branch (9)

This report shows up to 5 code coverage decreases.

• test DatadogLogsTests iOS 44.73% (Δ-0.16%) - Details
• test DatadogLogsTests tvOS 44.80% (Δ-0.15%) - Details
• test DatadogInternalTests tvOS 81.21% (Δ-0.06%) - Details
• test DatadogRUMTests iOS 79.38% (Δ-0.03%) - Details
• test DatadogWebViewTrackingTests iOS 23.05% (Δ-0.02%) - Details

[ncreated]

This change is intentional and makes the block() not throwing. Rationale is: the core being agnostic has no idea on how to handle or recover from the error that occurs in block passed to Feature (like RUM or SR). We had zero occurrence of "Failed to execute feature scope" in telemetry as no existing implementation of this block actually throws.

[maxep]

Nice work! so glad to see the tracer queue removed 🎉

[ganeshnj]

Good cleanup. Nice work.