RUMM-409 Update tracing with service, env and version

[ncreated]

What and why?

🚚 In #102, service, env and version attributes were unified for Log. In this PR, I merge master to tracing by also applying the same things to Span.

How?

There are three groups of commits in this PR:

• 3cc0bda - ca3cc71 - they update tracing with master, no CR required.
• 38f769a - this is the merge commit where I solved all the git conflicts.
• 4c2a1c1 - the most important commit, where Tracing feature gets updated with new service, env and version rules.

As discussed in #100, the default values resolution was moved from DDTracer.ResolvedConfiguration (deleted) to DDTracer itself. This was possible, as now we can make assertions on SpanBuilder:

func testDefaultTracer() {
    let tracer = DDTracer.initialize(configuration: .init()).dd

    let spanBuilder = (tracer.spanOutput as! SpanFileOutput)!.spanBuilder
    // ...
    XCTAssertEqual(spanBuilder.serviceName, "service-name")
    // ...
}

func testCustomizedTracer() {
    let tracer = DDTracer.initialize(
        configuration: .init(serviceName: "custom-service-name")
    ).dd

    let spanBuilder = (tracer.spanOutput as! SpanFileOutput)!.spanBuilder
    // ...
    XCTAssertEqual(spanBuilder.serviceName, "custom-service-name")
    // ...
}

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]

1. In order to create DDTracer, we need TracingFeature
2. In order to create TracingFeature, we need Datadog.instance
3. Datadog.instance has the default configuration in it

Is this order correct? Is that how we could get rid of resolve(config: ...)?

[ncreated]

1. In order to create DDTracer, we need TracingFeature

Yes 👍.

2. In order to create TracingFeature, we need Datadog.instance

No. TracingFeature only needs the value of struct Datadog.ValidConfiguration. This way we don't need mocking the Datadog.instance in tests that require TracingFeature.instance.

3. Datadog.instance has the default configuration in it

It only takes the configuration from the user: Datadog.Configuration, then resolves it with AppContext and creates the value of Datadog.ValidConfiguration.

It doesn't retain Datadog.ValidConfiguration. It just creates it and passes it to features, so it is accessible through:

• LoggingFeature.instance.configuration
• and TracingFeature.instance.configuration.