Align OTLP signal-specific properties with common fallback configuration

[somiljain2006]

Fixes #47962

Fix OTLP common property fallback handling. Align OTLP logging and tracing fallback behavior when resolving
common and signal-specific configuration properties. This change removes strict transport assertions from connection
details implementations since the effective transport may now be determined through fallback resolution between signal-specific and common OTLP properties.

Also adds regression tests covering:

• common transport fallback
• signal-specific transport override
• common timeout fallback
• signal-specific timeout override
• common compression fallback
• signal-specific compression override
• connect-timeout fallback behavior
• endpoint precedence
• header merging behavior

[mhalbritter]

Hello,

thanks for the PR.

the newly created class OtlpProperties creates the impression that all of the contained properties are always applicable, but that's not the case, isn't it?

The endpoint is used as a fallback, which is fine. The headers are merged, which is fine too.

The timeout is only used as a fallback for metrics via Micrometer, but org.springframework.boot.micrometer.metrics.autoconfigure.export.properties.PushRegistryProperties#readTimeout has a default value of 10s, therefore the fallback is never used. Same problem with connectTimeout. It's missing from tracing and logging completely.

transport is used as a fallback in tracing and logging, but not in metrics. That's because it's not possible to use gRPC transport with Micrometer, it only supports http.

compression doesn't seem to be used anywhere?

All in all, I don't think extracting all the common properties you did will work, either because not all signals support all settings or we have defaults in place, which renders the fallback obsolete.

It could work for endpoint and headers, though. In your PR, you append /v1/metrics to the base path for metrics, but this is missing for tracing and logging.

Do you want to rework the PR to just target endpoint and headers?

[mhalbritter]

Compression could work, too, if we drop the default values in the specific classes (OtlpMetricsProperties, OtlpTracingProperties and OtlpLoggingProperties).

for timeouts, i don't think this works as OTel uses connect timeout and timeout, while micrometer uses connect timeout and read timeout. I guess timeout from otlp is overall timeout (including connection timeout), while Micrometer's is not including connect timeout.

[mhalbritter]

See above.