add Resource getter to ExtendedOpenTelemetrySdk

[zeitlinger]

needed for open-telemetry/opentelemetry-java-contrib#2296 (comment)

[codecov]

Codecov Report

❌ Patch coverage is 80.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 90.11%. Comparing base (c67641c) to head (04521dd).

Files with missing lines	Patch %	Lines
.../extension/incubator/ExtendedOpenTelemetrySdk.java	66.66%	1 Missing ⚠️

Additional details and impacted files

@@ Coverage Diff @@ ## main #7832 +/- ## ============================================ - Coverage 90.11% 90.11% -0.01%  Complexity 7224 7224 ============================================ Files 821 821 Lines 21809 21811 +2 Branches 2136 2136 ============================================ + Hits 19654 19655 +1  - Misses 1486 1487 +1  Partials 669 669 

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[zeitlinger]

@jack-berg wdyt?

[jack-berg]

Oof I want this but..

1. Even with breaking changes allowed in ExtendedOpenTelemetry, they still cause churn and we don't want to offer a capability and later have to withdraw it.
2. In my mind ExtendedOpenTelemetry is the place we prototype new ideas, but the scope is still bound to concepts in the spec. To my knowledge the spec doesn't talk about this right now. Though I suspect that's changing with entities, and I want to make sure anything we do is aligned with whatever the current thinking is there. It doesn't have to perfectly embody the latest thinking, but it shouldn't be in tension with that.

[zeitlinger]

@jsuereth what do you think?

Is it in line with entities to expose the resource in the extended otel instance?