RUMM-696 Stop sending tracing Span for RUM Resources

[ncreated]

What and why?

🚚 This PR changes the logic of auto-instrumented, network Span generation depending of which feature (RUM or Tracing) is enabled. This is because recently our RUM backend started generating spans for RUM Resources on behalf of the SDK.

New behaviour, assuming that set(firstPartyHosts:) is set and DDURLSessionDelegate() is installed:

Tracing feature	RUM feature	Global.sharedTracer	Global.rum	1st party request	3rd party request
✅	❌	registered	-	send Span + inject tracing headers	-
❌	✅	-	registered	send RUM Resource	send RUM Resource
✅	✅	registered	registered	send RUM Resource with trace_id and span_id + inject tracing headers + inject x-datadog-origin: rum header	send RUM Resource

Also, appropriate warnings are printed on different misconfiguration, e.g. when Tracing auto-instrumentation is enabled, and a first party request is sent while Global.sharedTracer is not registered.

How?

Continuing what was started in #262, the logic of interceptor was simplified. Now, instead of two distinct handlers (for RUM and Tracing), it takes only one interface:

internal protocol URLSessionInterceptionHandler {
    func notify_taskInterceptionStarted(interception: TaskInterception)
    func notify_taskInterceptionCompleted(interception: TaskInterception)
}

implemented by URLSessionRUMResourceHandler and URLSessionTracingHandler.

Interceptor:

• injects / extracts SpanContext and custom x-datadog-origin: rum header into/from 1st party requests,
• notifies handler on interception start and completion.

Handler:

• URLSessionRUMResourceHandler - send RUM Resources and associate RUMSpanContext if set for the interception,
• URLSessionTracingHandler - send Span only for interceptions flagged as interception.isFirstPartyRequest.

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

[buranmert]

looks good, we can add one more test case though (i couldn't find if the case was already there)

[buranmert]

i guess we expect request.allHTTPHeaderFields == nil/unchanged in those 2 cases:

XCTAssertNil(interceptedThirdPartyRequest.allHTTPHeaderFields?)
XCTAssertNil(interceptedInternalRequest.allHTTPHeaderFields?)

?
and the next lines might already cover them:

XCTAssertEqual(thirdPartyRequest, interceptedThirdPartyRequest)
XCTAssertEqual(internalRequest, interceptedInternalRequest)

if HTTPHeaderFields are changed, those assertions fail; don't they?

[ncreated]

Yes, inspecting .allHTTPHeaderFields is redundant if we assert the full request equality later 👍. However, due to request equality bug in iOS 14 SDK: https://openradar.appspot.com/radar?id=4988276943355904 it seemed safer to do it before. To be more verbose on this, I added extra helper: assertRequestsEqual(_:_:) which implements the workaround. Redundant checks are now removed 👌.

[buranmert]

we can add already traced request (original request with tracing headers) test case here
i guess we expect to have the original headers after the interception, correct?

[ncreated]

Sorry, I don't understand 🙂. In quoted lines we do not test requests, but only internal state of the interceptor (interceptor.additionalHeadersForFirstPartyRequests).

There's no such case, where interceptor.modify(request:) is called for a request, which was previously intercepted. This contract is guaranteed in swizzler tests.

[xgouchet]

LGTM