Resource sdk.version support

[anuraaga]

Is your feature request related to a problem? Please describe.

Let me know if I'm missing it but I don't think the SDK fills in information about itself as described here

https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/resource/semantic_conventions/README.md#telemetry-sdk

Describe the solution you'd like

The SDK should fill in the SDK attributes. It'll probably need to propagate the current version into a Java resource file.

One thing that comes to mind is it seems to warrant exposing SDK resource attributes. Users may want to add custom attributes like here

https://github.com/aws-samples/aws-xray-sdk-with-opentelemetry-sample/blob/both-otel-and-xray/awsagentprovider/src/main/java/com/softwareaws/xray/opentelemetry/exporters/AwsTraceProvider.java#L40

And this would need some way to access the SDK resource so it can augment it, rather than replace it completely.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

[anuraaga]

I'm happy to implement this if there's agreement on a general approach. Mainly found this to make sure that I was worried I might squash it.

Given the Resource is composed of many different concepts (instance, container, process, SDK) that get merged, I wonder if moving resource to its own SPI would be cleanest. Then any and all relevant ResourceProviders can contribute attributes to the final resource.

[Oberon00]

Slightly related, one of the main arguments for #1058 is currently that it is currently very hard to explicitly set a resource that is used by the global TracerSdkProvider.

[bogdandrutu]

@Oberon00 Resource is an SDK component so it is not related to #1058 which allows to setup any implementation.

I would suggest probably to add a Setup method on the TraceProviderSDK that can be used to setup all the things Resource, IdGenerator, Config etc. We can have a behavior that before calling setup the SDK may be no-op or may have some defaults (we can discuss that).

[bogdandrutu]

Also I think the initial issue was about the SDK automatically adding the library version to the resource, which we should do anyway.

[anuraaga]

Yeah sorry for possible noise - it was about automatically adding the library version, but in a way that doesn't clobber with user-configured resources. The latter actually seems pretty tricky :)

[carlosalberto]

I would suggest probably to add a Setup method on the TraceProviderSDK that can be used to setup all the things Resource, IdGenerator, Config etc. We can have a behavior that before calling setup the SDK may be no-op or may have some defaults (we can discuss that).

Sounds great to me. +1 for some default values on start time.