What does this PR do?

The goal of this PR is to isolate the implementation from the API specification. The Datadog tracing integration is provided by the dd-trace-java library, which we moved into the dd-android-trace-internal module in a previous change.

We are now trying to finally eliminate opentracing dependencies and are facing the following issues:

1. The opentracing API specification is used as an internal layer for module communication. For example, the dd-android-sdk-trace-http module uses the following objects from opentracing: Span, Scope, etc. The diagram below displays the existing architecture:

graph BT
J(otel) --> H(io.opentelemetry)
B(trace) --> L(trace-internal)
M[ ]:::empty --> B
J --> L
F(trace-coroutines) --- M
B -- api --> A(io.opentracing)
E(sqldelight) --- M
D(okhttp) --- M
D -- api--> A
classDef empty width:0px,height:0px;

As you might have noticed, there are a lot of modules that are aware of the specification classes and are bound to a specific implementation of the opentracing specification, such as AndroidTracing.

2. The second problem is that most modules know not only the specifications, but also the implementation.
   A lot of downcasting logic can be found inside the integration module:

if (activeSpan is DDSpan) {
        activeSpan.traceId.toString()
    }

To solve the described issues and decouple the implementation from the internal and external specifications, we provide the following architecture:

graph BT
C --impl--> B(trace-internal)
C(trace) --api--> A(trace-api)
C --(ready to remove)--> O(io.opentracing)
M[ ]:::empty --> C
D(okhttp)  --- M
F(trace-coroutines) --- M
E(sqldelight) --- M
J(otel) --- M
J --> H(io.opentelemetry) 
classDef empty width:0px,height:0px;

This PR mainly includes:

1. The dd-sdk-android-trace-api module was added to provide the internal API specification for trace functionality.
2. The dd-android-sdk-trace module is now the only point that knows both the specification and the implementation.
3. The opentracing API specification was replaced with the dd-sdk-android-trace-api for all modules that used the opentracing specification previously.
   4.All api dependencies were replaced with implementation dependencies for all modules except for dd-sdk-android-trace-api.

TL;DR:
In this pull request, we isolated the specific implementation from the specification and removed all of the downcasting logic from the integration modules. Now, the only place where the implementation meets the specification is the dd-sdk-android-trace module.

Motivation

Why just not to use Otel's specification instead of opentraicing?

Otel requires API 26 or desugaring support

Why just not to use dd-sdk-android-trace-internal's interfaces as a specification?

Most of the files in the dd-sdk-android-trace-internal directory are written in Java because it adopts the dd-trace-java directory. Therefore, some Kotlin features, such as the internal modifier, will not work if they are made public. Additionally, dd-trace-java was initially designed for a server-side agent and contains specific methods that are not applicable to Android, which could confuse customers.

Additional Notes

Note that there is still dependency on opentracing and internal module mostly for tests. I decided to remove them in a separate PR to reduce amount of changes.

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)