Add EnvironmentResourceProvider

[jack-berg]

An option that may nicely cleanup the problem discussed here, where the autoconfigured resource from the environment is only accessible through via a roundabout API that instantiates an SDK.

This moves the environment resource logic to the io.opentelemetry.instrumentation:opentelemetry-resources, along side other resource providers. A ResourceProvider is provided, but you can also programatically access the environment resource via:

• EnvironmentResource.get() - access singleton resource which parses environment variables and system properties
• EnvironmentResource.create(ConfigProperties) - create an environment resource by parsing properties from ConfigProperties. Allows you to bring your own set of configuration overrides.

WDYT?

cc @jkwatson

[jack-berg]

I thought about moving this to opentelemetry-java/sdk/common, but doing so creates a circular dependency since this code depends on ConfigProperties (:sdk:common -> :sdk-extensions:autoconfigure-spi -> :sdk:common).

[jkwatson]

Seems like a totally reasonable approach to me! Only concern is the possibility of breaking existing users who might be expecting this one, but not have pulled in any other jars.

[jack-berg]

Only concern is the possibility of breaking existing users who might be expecting this one, but not have pulled in any other jars.

That's true.. a user that consumes autoconfigure direclty, without the agent, will need to add a dependency on this artifact to keep the same behavior. I think that's acceptable. Can emphasize it in release notes, and mention this instrumentation resource module in the opentelemetry.io docs to really drive home the importance.

[jack-berg]

Lets hold off merging this and decide if we prefer the approach outlined in opentelemetry-java#5500 instad.

[jack-berg]

Closing in favor of opentelemetry-java#5554.