Add experimental OpAMP client

[RassK]

What

Adds experimental opamp client.
More info in contrib repo:
https://github.com/open-telemetry/opentelemetry-dotnet-contrib/tree/main/src/OpenTelemetry.OpAmp.Client

Tests

Build was locally tested.
Additional tools are unit tested.

Checklist

• CHANGELOG.md is updated.
• Documentation is updated.
• New features are covered by tests.

[Kielek]

I have 2 concerns here

1. New transitive dependencies.
   • Google.Protobuf was already removed from the distribution in scope of update od OTel ADK to 1.11.0: 3986
   • System.Collections.Immutable - Do you any possibility to drop this dependency in Opam.Client package?
2. Lack of integration tests with OpAmp server. I see 2 options here
   • create mocked server as we have for OTLP protocol
   • Utilize some existing dockerized server.
     Adding this kind of tests can be done as follow up PR.

[RassK]

I have 2 concerns here

1. New transitive dependencies.

   • Google.Protobuf was already removed from the distribution in scope of update od OTel ADK to 1.11.0: 3986

I was looking what OpenTelemetry.Exporter.OpenTelemetryProtocol was doing. This experience could be transferred to OpAMP client as well.

• System.Collections.Immutable - Do you any possibility to drop this dependency in Opam.Client package?

Probably not. This may have to stay.
Update: @Kielek found a way to fix it, so we can go fully without deps

2. Lack of integration tests with OpAmp server. I see 2 options here

   • create mocked server as we have for OTLP protocol
   • Utilize some existing dockerized server.
     Adding this kind of tests can be done as follow up PR.

I could reuse OpAMP Go's example server.

[ysolomchenko]

I believe it makes sense to create separate settings for OpAMP and handle calculations there (ConnectionType and ServerUrl). This would allow us :

• Keep code consistency
• Add file-based configuration

[RassK]

I believe it makes sense to create separate settings for OpAMP and handle calculations there (ConnectionType and ServerUrl). This would allow us :

• Keep code consistency
• Add file-based configuration

Yes, this seems good change for this PR even.

[RassK]

Moving to draft. The plan is to implement the next version without deps.

[lachmatt]

Blocked at the moment by: #4783