Add back the otlpmetric{http,grpc} exporter code

[MrAlias]

Blocked by the metric SDK having a working example in the new_sdk/main branch

Removed in #2802

• internal transforms (Add back the otlpmetric transforms #3065)
• internal configuration (Restore the exporters/otlp/otlpmetric/internal/otelconfig package #3090)
• otlpmetric exporter (Add otlpmetric exporter #3089)
• otlpmetricgrpc client (Add back the otlpmetricgrpc exporter #3094)
• otlpmetrichttp client (Add back the otlpmetrichttp exporter #3097)
• internal integration testing
  • Client integration testing (Add exporters/otlp/otlpmetric/internal/otest #3125)
  • gRPC collector (Add integration and config testing to otlpmetricgrpc #3126)
  • HTTP collector (Add integration and config testing to otlpmetrichttp #3155)

[MrAlias]

Looking at the previous package structure, I do not think the otlpmetric.Exporter or otlpmetric.Client types should be re-introduced. Having this exporter type that needs an additional concept of a client is not useful to the user. It only adds to the mental strain of setting up an exporter having to know that you need a client in addition to this exporter. And in reality, the end-user never interacts with this type. They just call New from a client implementation package (e.g. otlpmetricgrpc.New).

Instead of bringing this confusion forward into the next release I propose these types are removed from the otlpmetric package, the implementation details of a client are not exposed from the otlpmetrichttp or otlpmetricgrpc packages, and instead those packages each have the following New functions:

func New(ctx context.Context, opts ...Option) (metric.Exporter, error)

[MrAlias]

Now is a good time to reduce the options included in the otlpmetricgrpc package. We should accept a gRPC connection that the user creates and just use that. We should stop creating and trying to manage gRPC connections with the exporter. Doing so would mean we would have to track non-stable gRPC features with our stable exporter and continually try to keep up with adding the same features gRPC does.

[MrAlias]

Now is a good time to reduce the options included in the otlpmetricgrpc package. We should accept a gRPC connection that the user creates and just use that. We should stop creating and trying to manage gRPC connections with the exporter. Doing so would mean we would have to track non-stable gRPC features with our stable exporter and continually try to keep up with adding the same features gRPC does.

This might not be possible if we plan to continue support for environment variables. A connection will need to be setup in that case.

[MrAlias]

Looking at the previous package structure, I do not think the otlpmetric.Exporter or otlpmetric.Client types should be re-introduced. Having this exporter type that needs an additional concept of a client is not useful to the user. It only adds to the mental strain of setting up an exporter having to know that you need a client in addition to this exporter. And in reality, the end-user never interacts with this type. They just call New from a client implementation package (e.g. otlpmetricgrpc.New).

Instead of bringing this confusion forward into the next release I propose these types are removed from the otlpmetric package, the implementation details of a client are not exposed from the otlpmetrichttp or otlpmetricgrpc packages, and instead those packages each have the following New functions:

func New(ctx context.Context, opts ...Option) (metric.Exporter, error)

Giving this some thought, the need for consistency out-weighs the improvements this alternate approach would offer. Users already using the otlptracegrpc exporter would be confused by the difference more than appreciative is my guess. I think moving forward with the original design makes sense here.

[MrAlias]

Closed by #3155