Instrumentation Configuration API (ConfigProvider / ConfigProperties) is not implemented

Instrumentation Configuration API (ConfigProvider / ConfigProperties) is not implemented

What's missing

The OpenTelemetry specification defines an Instrumentation Configuration API
that lets instrumentation libraries read declarative configuration relevant to
them. The two central components are:

• ConfigProvider — the entry point of the API. It provides access to
  configuration properties relevant to instrumentation, exposes a
  "get instrumentation config" operation returning the .instrumentation
  configuration node, and the API is expected to offer a global default
  ConfigProvider that can be accessed and set/registered.
  Status: Development.
• ConfigProperties — a programmatic, schemaless representation of a
  configuration mapping node, with type-safe accessors for scalars, mappings,
  sequences, and the set of present keys, and the ability to distinguish
  "present but null" from "not set". Status: Stable.

Spec references:

• API: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/api.md
• SDK: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/sdk.md

The SDK spec additionally requires that:

• The SDK provides an implementation of ConfigProvider, created from a
  ConfigProperties representing the .instrumentation mapping node
  (sdk.md#configprovider).
• The Create operation returns a ConfigProvider as one of the top-level
  SDK components, alongside the TracerProvider, MeterProvider,
  LoggerProvider, Propagators, and Resource
  (sdk.md#create).

Current state in opentelemetry-python

Python already has significant declarative-configuration support in the
opentelemetry-configuration package (parse/load_config_file,
configure_sdk, the in-memory OpenTelemetryConfiguration model, component/
plugin providers, and a configure_instrumentation helper). However, the
Instrumentation Configuration API surface itself is absent:

• There is no ConfigProvider type anywhere in the codebase.
• There is no ConfigProperties type (no schemaless, type-safe accessor
  API for reading an arbitrary configuration mapping node).
• There is no global default ConfigProvider with get/set/register
  semantics for instrumentation libraries to access.
• configure_sdk(...) returns None; the Create-equivalent path does not
  return a ConfigProvider among the produced components.

The one related piece, opentelemetry.configuration.instrumentation.configure_instrumentation,
implements a push model: it walks .instrumentation.python, resolves
opentelemetry_instrumentor entry points, and calls instrument() on each.
This is not the spec's pull model, in which an instrumentation library holds
a ConfigProvider, calls "get instrumentation config", and reads its own
configuration from the returned ConfigProperties.

How this was verified

Against upstream/main:

$ git grep -l "ConfigProvider\|config_provider" upstream/main -- '*.py'
# (no results)

The public API of the configuration package is:

# opentelemetry-configuration/src/opentelemetry/configuration/__init__.py
__all__ = [
    "ConfigurationError",
    "OpenTelemetryConfiguration",
    "configure_sdk",
    "load_config_file",
]

No ConfigProvider / ConfigProperties is exported or defined.

Proposed work

1. Add a ConfigProperties type implementing the spec's accessor requirements
   (scalars, nested mappings as ConfigProperties, sequences of scalars,
   sequences of mappings as ConfigProperties, key-set introspection, and
   present-but-null vs not-set distinction), in a Pythonic/type-safe manner.
2. Add a ConfigProvider type with a "get instrumentation config" operation
   returning the ConfigProperties for the .instrumentation node (returning
   an empty ConfigProperties when .instrumentation is not set), plus a
   global default ConfigProvider with access and set/register semantics.
3. Wire the SDK so the Create/configure_sdk path constructs and exposes a
   ConfigProvider built from the .instrumentation node, returned/available
   alongside the other top-level components.

Notes

• ConfigProvider is at Development stability in the spec, so the initial
  implementation can be marked experimental accordingly. ConfigProperties is
  Stable.
• This tracks parity with other SDKs (e.g. Java exposes
  openTelemetry.getConfigProvider()), enabling instrumentation libraries to
  consume declarative configuration in a spec-compliant way.

Start with opentelemetry-configuration/src/opentelemetry/configuration/init.py and the configure_sdk and load_config_file entry points, then compare their configuration model with the referenced API and SDK specifications. Done means ConfigProperties and ConfigProvider exist with the specified access and global-registration behavior, and configure_sdk exposes the provider alongside the other SDK components.