Opentelemetry-java: Add setup method to configure the OpenTelemetry API

[thisthat]

According to the specifications, the OpenTelemetry SDK must be programmatically configurable. The current initialization looks for implementations of the OpenTelemetry API via Service Provider and if no instance is found, it defaults to a no-op implementation. In the SIG call, we agreed that the default behavior should be no-op until a configuration is provided.

1058 provides a first implementation that allows to set up individually tracer provider, metric provider, and context manager. We should iterate over this proposal and making it friendly to the auto-instrumentation.

[carlosalberto]

I think we should still do the SPI thing we do at this moment, while also supporting explicit, manual configuration as done in #1058

[jkwatson]

I think @bogdandrutu was going to prototype an SDK that could also be a no-op until it had been configured, which would, I think, solve many of the startup-timing issues that make all of this extra tricky.

[bogdandrutu]

https://github.com/open-telemetry/opentelemetry-java/issues/1311#issuecomment-639607426

I have some questions about this:

1. Should we always require setup to be called? Probably yes - part of setup we should ask user to add the span processor.
2. What is the default behavior before setup? Should this be configurable? If yes, how?

[anuraaga]

My opinion is

1) require setup
2) everything no-op until it's called. Some background thing may happen before a user gets to setup the SDK (e.g., initialize db connection pool) and it would add noise if these got instrumented but without the proper setup.

[jkwatson]

Can we push this off until after GA? I think this is a purely additive change to the API/SDK, so it seems like this could be pushed off, especially as the instrumentation agent seems to be working fine for now.

[carlosalberto]

Technically we should implement this as part of the Specification (as mentioned by @thisthat in the issue description) - yet I feel this is indeed something that could be left as "Required for GA" but low priority (in case we cannot address all the items by deadline time).

@thisthat @anuraaga Sounds great? If not, please elaborate ;)

[jkwatson]

Heh. I wrote that specification, so I do think we should be programmatically configurable. But, I also think we could probably get away with only SPI for GA, if we need to.

[iNikem]

If SPI covers all configuration options that we want to provide, then it is certainly enough for GA. Other options, like setup method or such, can be added after GA.

[jkwatson]

Moving to after-ga. Please yell if you think this is actually needed for GA.

[jkwatson]

I think this would be satisfied by #1737 , yes?