Java8RuntimeMetricsProvider and Java17RuntimeMetricsProvider are not
@configuration classes and should not be registered as Spring
auto-configurations. Their presence causes Spring AOT processing to
fail with FileNotFoundException when the classes are not on the
classpath.

Signed-off-by: Gregor Zeitlinger <[email protected]>

…nfig registries

Signed-off-by: Gregor Zeitlinger <[email protected]>

Signed-off-by: Gregor Zeitlinger <[email protected]>

The Spring Boot starter's ThreadDetailsInstrumenterCustomizerProvider reads
from the declarative config path spring_starter > thread_details > enabled,
but the ConfigPropertiesBackedDeclarativeConfigProperties bridge only handles
paths starting with "java." or explicitly listed in SPECIAL_MAPPINGS. This
caused the property otel.instrumentation.common.thread-details.enabled to
have no effect in non-declarative-config mode, breaking smoke tests.
Signed-off-by: Gregor Zeitlinger <[email protected]>

…ExtendedOpenTelemetry path

Replace SPI-based ThreadDetailsInstrumenterCustomizerProvider with
ThreadDetailsAutoConfiguration that reads config directly from Spring
Environment, branching on declarative config vs properties-based like
EarlyConfig. Programmatically registers the customizer provider - no
static mutable fields needed.
Signed-off-by: Gregor Zeitlinger <[email protected]>

…ry to fix timing

The previous ThreadDetailsAutoConfiguration ran too late — Spring creates
beans on-demand via DI, so instrumenters were already built before the
flag was set. Moving it into the openTelemetry() bean methods guarantees
correct ordering.
Signed-off-by: Gregor Zeitlinger <[email protected]>

…thread-details-provider2

# Conflicts:
#	javaagent-extension-api/src/main/java/io/opentelemetry/javaagent/extension/instrumentation/internal/AgentDistributionConfig.java

- configureDeclarativeConfig now takes ConfigProvider and reads
  java.spring_starter.thread_details.enabled from the instrumentation config.
  The call site in OpenTelemetryAutoConfiguration passes SpringConfigProvider,
  which coerces Spring's flattened String values back to Boolean; the previous
  attempts via SdkConfigProvider/YamlDeclarativeConfigProperties silently dropped
  the flag because Spring's application.yaml pipeline stores every scalar as a
  String and YamlDeclarativeConfigProperties refuses to coerce.
- configureProperties keeps reading otel.instrumentation.common.thread-details.enabled
  from Environment for the properties-based path; no legacy fallback in the
  declarative path.
- Add declarative-config smoke test assertion: enable thread_details in the
  testDeclarativeConfig application.yaml and assert thread.id / thread.name
  appear on the server span.
- Simplify segments[0] == "agent" guard in ConfigPropertiesBackedDeclarativeConfigProperties
  (drop dead segments.length check, work off translatedPath).

…/github.com/trask/opentelemetry-java-instrumentation into declarative-config-thread-details-provider2

# Conflicts:
#	declarative-config-bridge/src/main/java/io/opentelemetry/instrumentation/config/bridge/ConfigPropertiesBackedDeclarativeConfigProperties.java
#	smoke-tests-otel-starter/spring-boot-2/src/testDeclarativeConfig/java/io/opentelemetry/spring/smoketest/OtelSpringStarterSmokeTest.java