Break sdk incubator dependency on autoconfigure

[jack-berg]

Related to #7292

Right now declarative config in the opentelemetry-sdk-extension-incubator module depends on autoconfigure for a few key bits of functionality:

• SpiHelper, for ordered loading utlities, AutoConfigureListener state management
• ResourceConfiguration to leverage the autoconfigure logic for parsing otel.service.attributes, which is reused to handle .resource.attributes_list

These dependencies require autoconfigure to load file config via reflection in order to avoid a circular dependency. Ultimately, we want some sort of dedicated config module, with autoconfigure having a dependency on it. This requires we break the incubator -> autoconfigure dependency, which is what this PR does.

Changes:

• Add new ComponentLoader#loadList utility method to load SPI to a list intead of iterable. We do this in a number of places so just add a utility method to make it more convenient.
• Add new Ordered#loadOrderedList utlity method. This logic was in SpiHelper, but doing it in multiple places suggests extracting a utility method.
• Remove all declarative config references to SpiHelper, instead performing the state management directly within DeclarativeConfigContext. SpiHlper really ought to be named AutoConfigureContext, but will save that for a future work.
• Replace autoconfigure reflective access to declarative config with compileOnly dependency
  • One thing that was tricky here was how to get the declarative config resource. Currently, we reflectively access via DeclarativeConfigContext, but we're trying to get rid of this reflection and continuing to use DeclarativeConfigContext would negate or require a broader refactor to make DeclarativeConfigContext internal / public. I ended up solving this by accessing the resource reflectively from SdkMeterProvider.
• Add a gradle task to copy the autoconfigure otel.resource.attributes parsing logic to declarative config. This allows the code to be reused without having to move to a central public location like opentelemetry-sdk-common, and without having to manually synchronize the content.
• Tweak tests to reflect changes

[codecov]

Codecov Report

❌ Patch coverage is 95.83333% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.27%. Comparing base (2682f15) to head (e98f56c).
⚠️ Report is 11 commits behind head on main.

Files with missing lines	Patch %	Lines
...pentelemetry/sdk/autoconfigure/IncubatingUtil.java	71.42%	3 Missing and 1 partial ⚠️
...lemetry/sdk/autoconfigure/EnvironmentResource.java	96.29%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #8242      +/-   ##
============================================
- Coverage     90.32%   90.27%   -0.06%     
- Complexity     7654     7656       +2     
============================================
  Files           843      844       +1     
  Lines         23080    23073       -7     
  Branches       2312     2315       +3     
============================================
- Hits          20848    20830      -18     
- Misses         1516     1522       +6     
- Partials        716      721       +5     

☔ 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]

Looks great - I've created jack-berg#24 which would get rid of the remaining reflection usage.

I'm approving regardless - I know we discussed Resource quite a bit 😄

[jack-berg]

Merged! Yeah I figured we'd ultimately have to go in this type of direction, but was resisting adding "yet another component wrapper", adding to the list of:

• OpenTelemetrySdk
• ExtendedOpenTelemetrySdk
• AutoconfiguredOpenTelemetrySdk
• DeclarativeConfigResult <-- new

Of course this could be solved by exposing Resource from OpenTelemetrySdk or ExtendedOpenTelemetrySdk but that comes with verification problems, since it will be tricky to retrofit the existing APIs to guarantee that the ExtendedOpenTelemetrySdk#getResource matches the resource associated with SdkTracerProvider, SdkMeterProvider, SdkLoggerProvider.

AutoConfiguredOpenTelemetrySdk is a no go since its in autoconfigure.

Going to do a small additional change to move DeclarativeConfigResult to the main package instead of internal, since its a key part of the API there's really no point hiding it in an internal.

[zeitlinger]

Going to do a small additional change to move DeclarativeConfigResult to the main package instead of internal, since its a key part of the API there's really no point hiding it in an internal.

I thought it would be an easier sell in internal 😏