Registry and factories for Exporters and Aggregators

[jmacd]

Any efforts to build a configurable SDK for tracing or metrics will have to directly link all their dependencies. This will create large binaries that include lots of unused code. For example, a configurable metric SDK might be able to apply the DDSketch algorithm, but it will be undesirable to include that code if it is not used.

We will need a way to locate exporters (Tracing and Metrics) and aggregators (only Metrics) without a direct dependency, but code constructed through a factory will also require a way to configure itself. The otel-collector has built a framework for this using spf13/viper, but (a) it's a manual effort (spf13/viper doesn't offer much help) and (b) it's not clear that spf13/viper is a suitable dependency. Maybe the mitchellh/mapstructure package is suitable.

(Possibly this problem is not large enough that it matters to Tracing SDKs. We have e.g., #796 adding support for environment variable configuration, so perhaps no "configurable tracing SDK" is needed, meaning to switch between OTLP and Jaeger requires recompiling.)

To close this issue, at least for metrics, we should have a way to locate a named Aggregator implementation and configure it from an external source, somehow. The metrics aggregators that require configuration are Histogram and DDSketch. All of the metrics exporters require configuration. Until this is possible, it will be difficult to construct a realistic configurable SDK--we'll have to take every dependency instead.

[MrAlias]

This looks like it will be resolved with open-telemetry/opentelemetry-go-contrib#2753