chore: decouple opentelemetry-proto from opentelemetry-sdk

[scottgerring]

Summary

This refactors opentelemetry-proto so it only contains generated OTLP protobuf types. The diff is substantial because of the orphan rules - opentelemetry-otlp cannot implement the conversion traits for foreign types into foreign types. My feeling is that we just need to pull off the bandaid here!

The SDK/api-aware transform helpers have been moved into opentelemetry-otlp, where they are used by the exporters. This removes the direct opentelemetry / opentelemetry_sdk dependency from opentelemetry-proto and makes the crate usable by consumers that only need OTLP wire-format types. This will also provide other options to structure changes like #3460 , where we could benefit from having the dependency the other way around (although this is by no means a done deal).

Changes

• Remove the public opentelemetry_proto::transform module.
• Move SDK/API → OTLP protobuf transformation logic into a private opentelemetry-otlp::transform module.
• Update OTLP exporters to use the local transform helpers.
• Update opentelemetry-proto docs and changelog to describe the crate as generated protobuf types only.

Prior art / related work

This implements the SDK-decoupling part of:

• Simplify opentelemetry-proto: SDK decoupling, gRPC separation #3045 - “Simplify opentelemetry-proto: SDK decoupling, gRPC separation”
• Proposal: Rename opentelemetry-proto/src/proto/tonic module #2508 - earlier proto layout / generated-code cleanup discussion; later folded into Simplify opentelemetry-proto: SDK decoupling, gRPC separation #3045
• feat: Simplify opentelemetry-proto: SDK decoupling and gRPC separation #3046 - earlier attempted implementation of proto simplification / SDK decoupling
• Decouple opentelemetry-proto from SDK: Make SDK optional #3353 - earlier attempted implementation that made SDK dependencies optional rather than fully moving transforms out
• [Feature]: Decouple prost from OTLP/JSON #3419 / feat: Decouple prost from otlp json #3451 - adjacent work to reduce unnecessary proto/exporter dependencies for OTLP JSON/prost usage

[scottgerring]

@lalitb I know you've worked on this before; it would be great to get your high-level opinions on this so I can push it in the right direction. I'm not sure if i've missed some important nuance given this has come up a few times but never landed!

[codecov]

Codecov Report

❌ Patch coverage is 46.46617% with 356 lines in your changes missing coverage. Please review.
✅ Project coverage is 83.0%. Comparing base (dfdc478) to head (ec5443d).
⚠️ Report is 26 commits behind head on main.

Files with missing lines	Patch %	Lines
opentelemetry-otlp/src/transform/metrics.rs	9.8%	202 Missing ⚠️
opentelemetry-otlp/src/transform/logs.rs	69.9%	68 Missing ⚠️
opentelemetry-otlp/src/transform/trace.rs	47.6%	45 Missing ⚠️
opentelemetry-otlp/src/transform/common.rs	74.3%	30 Missing ⚠️
opentelemetry-otlp/src/exporter/tonic/metrics.rs	0.0%	3 Missing ⚠️
opentelemetry-otlp/src/exporter/http/logs.rs	0.0%	2 Missing ⚠️
opentelemetry-otlp/src/exporter/http/trace.rs	0.0%	2 Missing ⚠️
opentelemetry-otlp/src/exporter/tonic/logs.rs	0.0%	2 Missing ⚠️
opentelemetry-otlp/src/exporter/tonic/trace.rs	0.0%	2 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##            main   #3512     +/-   ##
=======================================
+ Coverage   82.8%   83.0%   +0.1%     
=======================================
  Files        130     129      -1     
  Lines      27289   27229     -60     
=======================================
- Hits       22622   22614      -8     
+ Misses      4667    4615     -52     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[TommyCpp]

More of a style suggestion. But I wonder if it would be better to package this as a extension trait against SDK resource, instead of resource_to_attributes_with_schema function

[scottgerring]

@TommyCpp thanks for taking a look, and good point!

I think this conversion is one of the few places where a method-style API could be reasonable, since it’s a high-level boundary used directly by the exporters.

That said, I’m a bit hesitant to make it look like an operation that inherently belongs on Resource: this is really an OTLP/proto-specific projection of a Resource, including how we carry the schema URL alongside attributes. Since we already have a local target type here, From<&Resource> gives us a short call site without adding an extension trait or implying this is a general Resource capability; maybe something like this? -->

Suggested change

	self.resource =
	self.resource = resource.into();

For the broader transform module I’d probably keep the explicit *_to_proto functions, since most are lower-level implementation details or external-to-external mappings where From isn’t available due to orphan rules.

[github-actions]

Thank you for your contribution! This PR has been automatically marked as stale because it has not had activity in the last 14 days. This may be due to a delay in review on our side or awaiting a response from you; either is fine, and we appreciate your patience.

It will be closed in 14 days if no further activity occurs. Pushing a new commit or leaving a comment will remove the stale label and keep the PR open.

[scottgerring]

This isn't stale, it just needs a review :D

[cijothomas]

@lalitb Can you review this one?

[github-actions]

Thank you for your contribution! This PR has been automatically marked as stale because it has not had activity in the last 14 days. This may be due to a delay in review on our side or awaiting a response from you; either is fine, and we appreciate your patience.

It will be closed in 14 days if no further activity occurs. Pushing a new commit or leaving a comment will remove the stale label and keep the PR open.

[scottgerring]

@lalitb do you have time to look at this?