OTLP Exporter: Consider internalizing Google.Protobuf

[alanwest]

#4201 upgraded the OTLP exporter's dependency on Google.Protobuf from 3.19.4 to 3.22.0.

This causes issues for the opentelemetry-dotnet-instrumentation project (see: open-telemetry/opentelemetry-dotnet-instrumentation#2220). Currently, their project is tightly coupled to the SDK project and any changes in transitive dependencies can cause them issues.

They have requested that we either:

1. Downgrade back to 3.19.4
2. Internalize Google.Protobuf

Downgrading is not desirable as consumers of the OTLP exporter would see degraded performance unless they were to explicitly reference Google.Protobuf 3.22 or greater. Therefore, this issue is for discussing the possibility of internalizing Google.Protobuf.

Ultimately, this should be an issue for the opentelemetry-dotnet-instrumentation project to solve. It is too prohibitive for the SDK project to not be able to upgrade its transitive dependencies or add new ones as necessary. However, it may be reasonable to address the problem only for Google.Protobuf because:

1. Google.Protobuf is only used by the internal code generated from the OTLP protos.
2. In the longer term, we want to try eliminating our dependency on Google.Protobuf altogether, and implement our own protobuf serialization. The opentelemetry-java project has done this.

As such, an intermediate step towards eliminating Google.Protobuf could be to first internalize it. This would be solely for offering an immediate solution unblocking the opentelemetry-dotnet-instrumentation project.

There are two potential methods for internalizing Google.Protobuf.

1. Forklift Google.Protobuf code into the OTLP exporter project.
2. Use a tool like ILRepack.

Forklifting Google.Protobuf may be the more desirable option. It would probably enable us to more easily analyze it for compatibility for things like AOT, trimming, and single-file deploys. However, it is a lot of code (~50k lines). It is possible to identify and remove unused code, but this could be very time consuming and more difficult to maintain.

[rajkumar-rangaraj]

Fixed with 1.11.0-rc.1 version of OpenTelemetry.Exporter.OpenTelemetryProtocol package.