Declarative spring_starter.debug never enables span logging

[colamong]

Describe the bug

In declarative configuration mode, instrumentation/development/java/spring_starter/debug never
takes effect, so span logging cannot be enabled at all on that path.

Two things combine:

1. DeclarativeConfigLoggingExporterAutoConfiguration is missing from both auto-configuration
   registration files (AutoConfiguration.imports and spring.factories), so Spring Boot never
   discovers it and its DeclarativeConfigurationCustomizerProvider bean is never created. This is
   the same omission as Register LoggingExporterAutoConfiguration so otel.spring-starter.debug works #19725, which fixes the properties-mode counterpart.

2. Registering it is not sufficient. SpanLoggingCustomizerProvider.isEnabled reads the flag via
   the upstream SdkConfigProvider:

   return SdkConfigProvider.create(DeclarativeConfiguration.toConfigProperties(model))
       .getInstrumentationConfig("spring_starter")
       .getBoolean("debug", false);

   In the Spring starter, EmbeddedConfigFile builds the declarative model from
   Map<String, String>, so every scalar arrives as a String. getBoolean("debug", false)
   does not coerce, and returns false for a configured debug: true.

   That is exactly why this module already carries SpringConfigProvider and
   SpringDeclarativeConfigProperties, whose Javadoc says it "tries to coerce types, because
   spring doesn't tell what the original type was" — but isEnabled does not go through them.

Observed while working on #19725: with the class registered, the provider bean is created and
consumed, but the exporter is still not installed. Reading the same key directly shows
getString("debug") → "true" while getBoolean("debug", false) → false.

Steps to reproduce

Use the Spring Boot starter with declarative configuration and set
instrumentation/development/java/spring_starter/debug: true. No LoggingSpanExporter is
installed and no spans are printed.

Expected behavior

Enabling the declarative spring_starter.debug flag installs the logging span exporter, matching
the behaviour of otel.spring-starter.debug in properties mode.

Actual behavior

The flag is ignored. Even with the auto-configuration registered, isEnabled evaluates to false
because the configured value is a String and getBoolean does not coerce it.

Javaagent or library instrumentation version

main (verified at 4225fbe)

Environment

JDK 21, Spring Boot 3.2.4 / 2.6.15

Additional context

There seem to be at least three ways to fix this, and I did not want to pick one without
maintainer input, which is why #19725 deliberately leaves the declarative class out:

1. Have isEnabled read through the Spring-aware coercing provider
   (SpringConfigProvider / SpringDeclarativeConfigProperties) instead of SdkConfigProvider.
2. Preserve scalar types in EmbeddedConfigFile instead of flattening everything to String.
3. Make the upstream getBoolean coerce string values — SpringDeclarativeConfigProperties has a
   TODO pointing at DeclarativeConfigProperties: no way to coerce types without triggering warnings opentelemetry-java#8101, which looks related.

Whichever direction is preferred, the registration entries for
DeclarativeConfigLoggingExporterAutoConfiguration need to be added as part of it. Happy to
send a PR once the direction is settled.

[colamong]

#19725 is approved and awaiting merge, so I would like to pick this one up next.

My preference is option 1, driven by consistency rather than personal taste. OpenTelemetryAutoConfiguration already routes declarative instrumentation configuration through SpringConfigProvider (the coercing copy), and DeclarativeConfigLoggingExporterAutoConfiguration is the only place in this module building an SdkConfigProvider directly. Option 1 does not introduce a new pattern; it removes an outlier.

SpringConfigProvider already has the necessary overload:

static SpringConfigProvider create(OpenTelemetryConfigurationModel model, ComponentLoader componentLoader)

so the call site change is minimal. Two wrinkles I would appreciate your steer on:

• Visibility. SpringConfigProvider is package-private in ...spring.autoconfigure, while the logging auto-configuration sits in ...autoconfigure.internal.instrumentation.logging. Widening its visibility or adding a small accessor is a judgment call I would rather not make unilaterally.
• Where the ComponentLoader comes from. We cannot reuse the SpringConfigProvider instance on SpringOpenTelemetrySdk, because DeclarativeConfigurationCustomizerProvider runs while the SDK is still being built.

On the alternatives: option 3 looks like the proper long-term fix, but open-telemetry/opentelemetry-java#8101 is still open. SpringDeclarativeConfigProperties already carries a TODO noting its copy collapses into a thin decorator once that lands; option 1 will follow along cleanly at that point rather than blocking on upstream progress now. Option 2 has the widest blast radius for the narrowest bug, modifying how every Spring-sourced scalar behaves rather than addressing only this flag.

Whichever direction you prefer, I will include the missing AutoConfiguration.imports and spring.factories entries for DeclarativeConfigLoggingExporterAutoConfiguration, plus a test that boots through real @EnableAutoConfiguration discovery rather than AutoConfigurations.of(...) — the same shape as #19725, since it was that pattern which let the original omission go unnoticed.