Discuss migrating dynamic-control from ConfigProperties to DeclarativeConfigProperties

Summary

dynamic-control still uses ConfigProperties internally in a few places, and a follow-up idea was to replace those usages with DeclarativeConfigProperties.

That needs design discussion first.

Why discuss first

A key concern is that the current TelemetryPolicySamplerComponentProvider path uses SystemPropertyFallbackConfigProperties, which manually reads from system properties / env vars.

That is important because it violates the spirit of dynamic-control's declarative config path: when dynamic-control is configured through declarative config, we should be very clear whether it is supposed to honor only the declarative config model, or whether it is also allowed to reach out to unrelated system properties / env vars on its own.

A naive migration away from ConfigProperties risks either:

• preserving behavior that we may not actually want to preserve, or
• accidentally changing behavior without first agreeing what the intended behavior should be.

So before changing dynamic-control to use DeclarativeConfigProperties throughout, we should clarify:

• whether dynamic-control should manually read system properties / env vars at all in declarative-config mode
• which config in dynamic-control is intentionally declarative-only
• whether any fallback semantics are intentional, accidental, or need to be split by use case
• what the desired API shape is for sources/providers such as OpampPolicyProvider

Scope candidates

Potential follow-up work after agreement:

• TelemetryPolicySamplerComponentProvider
• PolicyInit
• SourceKind
• OpampPolicyProvider
• related tests

Context

This came up while reducing deprecated DeclarativeConfigPropertiesBridgeBuilder usage in:

• https://github.com/open-telemetry/opentelemetry-java-contrib/pull/2988

Review PR 2988 and inspect the listed entry points: TelemetryPolicySamplerComponentProvider, PolicyInit, SourceKind, and OpampPolicyProvider, along with their related tests. The discussion is done when the intended system-property and environment-variable fallback semantics, declarative-only configuration boundaries, and provider API shape are agreed and the follow-up work is clearly scoped.