Reduce set of published artifacts

[jack-berg]

We publish a lot of artifacts, and it's cumbersome for users to sort through which are needed. There's opportunity to reduce the sprawl, partially made possible by the recent stabilization of metrics. Here are some simplification opportunities:

• ~~Stop publishing opentelemetry-context, instead merging it into opentelemetry-api.~~ Won't do - this separation is intentional.
• Stop publishing signal specific sdk artifacts. We still need a separate artifact for the unstable opentelemetry-sdk-logs and opentelemetry-sdk-testing, but we can merge opentelemetry-sdk-common, opentelemetry-sdk-metrics, and opentelemetry-sdk-metrics into opentelemetry-sdk.
• ~~Stop publishing signal specific otlp grpc artifacts. We still need a separate artifact for the unstable opentelemetry-exporter-otlp-logs, but we can merge opentelemetry-exporter-otlp-trace and opentelemetry-exporter-otlp-metrics into opentelemetry-exporter-otlp.~~ #4494.
• ~~Stop publishing signal specific otlp http artifacts, preferring a combined artifact. We still need a separate artifact for the unstable opentelemetry-exporter-otlp-http-logs, but can start publishing opentelemetry-exporter-otlp-http combining opentelemetry-exporter-http-trace and opentelemetry-exporter-http-metrics.~~ #4499
• ~~Stop publishing opentelemetry-exporter-jaeger-proto. Its for internal use only for opentelemetry-exporter-jaeger and I believe that the jaeger exporter doesn't rely on it being published.~~ #4496.

One of the themes of simplifications is to remove artifacts for individual signals. In the past we've argued that part of the value of otel is a single set of APIs / SDKs for all three signals. This is embodied in opentelemetry-api, which includes the APIs for tracing and metrics. We should follow that precedent with other artifacts.

[jkwatson]

• Stop publishing opentelemetry-context, instead merging it into opentelemetry-api.

There was an explicit ask early-on to have this be a separate artifact that could be used outside the scope (heh) of the API.

• Stop publishing signal specific sdk artifacts. We still need a separate artifact for the unstable opentelemetry-sdk-logs and opentelemetry-sdk-testing, but we can merge opentelemetry-sdk-common, opentelemetry-sdk-metrics, and opentelemetry-sdk-metrics into opentelemetry-sdk.

This was also done by request from a user who wants to be able to only use individual signals and possibly replace others (or ignore them). I think @kenfinnigan was the original requestor.

[jack-berg]

Found #575 that explains the desire to keep opentelemetry-context separate. I think the explanation of having a standalone context API to not be tied to a framework like grpc or spring web flux tracks is convincing.

Found #1460 that encompasses the discussion about separate SDK components. Modularizing the SDK has made it easier to cherry pick parts of the otel SDK implementation while plugging in your own implementation for others. But this comes at the price of sprawl: more published artifacts, less intuitive codebase. The modular SDK seems to have won on the argument of allowing a smaller set of classes for the scenario where you cherry pick the parts of the SDK. IMO, this is a weak argument because a single artifact doesn't preclude you from cherry picking parts of the SDK, you just have to bring along classes you don't want. For cases where removing unused classes is important, progaurd can be used. Increased sprawl and a less intuitive code base is a high price to pay to accommodate the edge case of wanting to cherry pick and having strict dependency size requirements.

[jack-berg]

I'm going to close this. The last remaining item is to stop publishing separate SDK artifacts. I don't think this is a good idea, but there doesn't seem to be agreement and is a much narrower scope of this issue's title. If others feel the same as me, we can revisit the subject in the future.