Configuration and Debug logging.

[MadVikingGod]

Problem Statement

It is difficult to understand how the SDK is configured in a running system. When debugging a problem our main resource right now is to "Also include the stdout exporter". If the SDK was able to report in some way its configuration and any major runtime events the debugging story could start with validating the configuration is correct.

Proposed Solution

Use the logging facilities created in #2343 to log the configuration of major components. For example

• TracerProvider creation
• Tracer creation
• Exporting a batch (debug)

Because most of the concrete structs we use intentionally have no exported fields they will be displayed in a rather unhelpful way. A stdouttrace Exporter for example would be represented as {}, to solve this we should utilize the logr's Marshaler interface to represent the types in a meaningful way.

Aditionally, because we use a number of interfaces to provide extensibility, for example with exporters, they are stored in higher-level types with generic names. For example if we were to marshal a BatchSpanProcessor it would have something like {... SpanExpoter: {... <Config details of the exporter>...}}. My recommendation is that we use as a convention an additional field in our Marshal output of Type that is a hardcoded string of the concrete type that we are marshaling.

Alternatives

We could instead of using the Marshal function include logging statements when the individual components are created. I opted aginst this because it wouldn't give a full picture of what the trace pipelines are. We would know that we created a stdout exporter, and an OTLP exporter, but we wouldn't necessarily be able to attribute a particular exporter to a tracerProvider.

Additional Context

Because of the structure of logr we only call the "Marshaler" interface if the log message meets the verbosity of the logger. This allows us a bit of liberty in MarshalLog() functions to do more expensive things because they will only be called if verbosity is high enough, 1+ for Info and 5+ for Debug, where we would expect to take a performance hit.