[loader] Too easy to configure no-op implementation by mistake

[Oberon00]

From #29 (comment)

The current lazy-loading behavior makes it easy to accidentally create a no-op tracer that sticks around. E.g. if the configured API implementation is decided after making an HTTP request and the used HTTP library is instrumented, the no-op tracer would be installed by the loader (and it's not exchangeable).

Several possible solutions come to my mind:

• Just provide setters that directly set the global objects. That would also resolve [loader] Decide setter/envvar interaction & behavior with multiple setter calls #44. Disadvantage: We allow changing an existing implementation and any loader logic is effectively circumvented if the app uses the setter.
• Don't load implicitly, explicitly require a call to loader.load (this would require moving the storage of the global objects and factory callbacks back to the loader to be implementable). Before that, all getters will return no-op.
• Provide loader.finish_configuration(). Similar to load but does not load immediately, only signals to getters that next time they are called they should load their component.

[codeboten]

Should this be closed with the changes in #123?

[andrewhsu]

Looks like related PR #466 did changes for configuration.

[c24t]

Yup, this is obsolete as of #466.