feat: auto-discover instrumentation plugins

[zhongkechen]

Summary

• discover versioned instrumentation plugin providers selected through DURABLE_EXECUTION_PLUGINS
• preserve configured ordering, explicit plugin precedence, and actionable validation errors
• expose the OTel plugins as otel-invocation and otel-execution entry points
• document configuration and provider authoring

Testing

• hatch run test:all
• hatch run types:check
• hatch run dev-otel:test -q
• hatch run dev-core:test -q -k plugin_discovery
• hatch fmt --check
• built the OTel wheel and verified both packaged entry points

Closes #618

[github-actions]

Codex AI review

No actionable findings. Residual risk: no Lambda end-to-end test verifies entry-point metadata survives deployment packaging and initializes correctly at cold start.

Reviewed commit 3a7ef0a277d0d19a7288bd8ac8652a14a9234e16. Workflow run

[github-actions]

Claude AI review

Review: feat: auto-discover instrumentation plugins

This PR adds environment-driven discovery of instrumentation plugins (DURABLE_EXECUTION_PLUGINS) resolved through the aws_durable_execution.plugins entry-point group, a versioned DurableInstrumentationPluginProvider factory, a PluginLoadError exception, and two OTel entry points (otel-invocation, otel-execution). I reviewed the discovery logic, the decorator integration, the OTel providers, version/dependency pins, and the test coverage.

No actionable correctness, determinism, serialization, concurrency, or API-compatibility findings. The implementation is solid:

• Discovery/parse logic correctly rejects empty and duplicate names, reports missing vs. ambiguous providers, wraps enumeration/load/factory failures in PluginLoadError, validates the provider type, API version, declared plugin type, and the concrete plugin type. Precedence (explicit-first, first-registration-wins) is keyed on the concrete type and matches the documentation.
• Determinism/replay: plugins are resolved once at decorator/cold-start time and reused across warm invocations; env vars are constant per container. Plugins are observability-only and don't touch checkpoint state, so no replay-determinism impact. load_configured_plugins(None) with no env var returns [], preserving prior PluginExecutor(None) behavior.
• API compatibility: the OTel providers are cheap module-level singletons whose factory (the plugin class) is only invoked when selected; both plugin constructors accept config=None. The Callable import and forward references in plugin.py are present. The OTel dependency bump to >=1.8.0 correctly gates the new DurableInstrumentationPluginProvider import. Group name, entry-point names, and README examples are all internally consistent.
• Tests are thorough across both packages (parse errors, ordering, missing/ambiguous/invalid providers, load/factory failures, precedence, and end-to-end entry-point loading).

Residual (non-blocking) considerations — no change requested

• The OTel package and the test-pypi-otel hatch env now require aws-durable-execution-sdk-python>=1.8.0 from PyPI; those installs won't resolve until 1.8.0 is published, so release ordering matters (expected for a version-bump PR).
• Plugins selected only via DURABLE_EXECUTION_PLUGINS do not emit the provisional FutureWarning that the plugins= decorator argument does, even though the whole plugin surface is still experimental. This is a UX/consistency choice, not a defect.
• Configuring both otel-invocation and otel-execution simultaneously instantiates two OTel plugins that each configure providers/instrumentation; this is a documented user choice, not a code issue.

Reviewed commit 3a7ef0a277d0d19a7288bd8ac8652a14a9234e16. Workflow run