[feature request] Adopt Microsoft.Extensions.Options async validation at startup

[ViveliDuCh]

Is your feature request related to a problem?

Today, configuration/options used by OpenTelemetry (exporters, processors, resource detectors, samplers, etc.) can only be validated synchronously via Microsoft.Extensions.Options (IValidateOptions<T> / DataAnnotations). Scenarios that require async work at startup — verifying an OTLP endpoint is reachable, resolving a token from a secret store, probing a collector's capabilities, or checking a remote sampling config — currently force users to either: (a) block on .GetAwaiter().GetResult() inside a sync validator (deadlock/perf risk), (b) defer validation to first-export (failures surface late, often in production), or (c) write bespoke IHostedService pre-flight checks that bypass the Options validation pipeline.

What is the expected behavior?

OpenTelemetry .NET's hosting integration (OpenTelemetry.Extensions.Hosting) adopts the newly merged async options validation APIs in Microsoft.Extensions.Options so users can register async validators for OTel options and have them run at startup with proper async semantics.

Relevant merged work in dotnet/runtime:

• Async Options Validation — proposal dotnet/runtime#128100, PR dotnet/runtime#128788 (merged)
• Async DataAnnotations bridge for Options — proposal dotnet/runtime#129056, PR dotnet/runtime#129218 (merged)
• Umbrella effort: Async Validation for DataAnnotations — dotnet/runtime#128096

Scope note: this iteration is startup-only; lazy validation via IOptions<T>.Value is deferred.

Concrete candidate scenarios in OTel .NET:

1. OtlpExporterOptions — async reachability/handshake check against Endpoint before the host starts.
2. Authentication options — async resolution of bearer tokens / certificates from Azure Key Vault, AWS Secrets Manager, etc., validated at startup.
3. Resource detector options — async detection (cloud metadata endpoints) validated before pipeline construction.
4. Sampler configuration — async fetch/validation of remote sampling rules.
5. Prometheus exporter — async port-availability / scrape-endpoint validation.

Runnable demos covering the API shape:

• https://github.com/ViveliDuCh/async-validation-demo/tree/api-proposal-samples/src/Options
• https://github.com/ViveliDuCh/async-validation-demo/tree/api-proposal-samples/src/Options/ConsoleAppSamples

Which alternative solutions or features have you considered?

• Sync IValidateOptions<T> with .GetAwaiter().GetResult() — risks deadlocks and blocks the startup thread.
• Custom IHostedService that runs pre-flight checks — works but bypasses the Options validation pipeline, duplicates error-reporting, and isn't discoverable to consumers using ValidateOnStart().
• Deferring validation to first export — failures surface late and are harder to diagnose in production.
• Keeping the status quo (no async startup validation) — leaves the deadlock/late-failure footguns in place for any OTel option that needs I/O to validate.

Additional context

Goal: enable OTel .NET options that need I/O at startup (endpoint reachability, secret/token resolution, remote sampling config, cloud metadata, etc.) to be validated through the standard Microsoft.Extensions.Options pipeline instead of via sync-over-async workarounds or bespoke IHostedService pre-flight checks.

Cross-reference context: shipping in .NET 10 (Microsoft.Extensions.Options 10.0+).

[martincostello]

This sounds reasonable.

As it's new functionality in .NET 11, this would make the most sense to build on top of #6899, but only make available to the relevant TFMs that have access to the new APIs (we will not upgrade the packages for all TFMs just to enable this).