Add default constructor support for OTel plugin

[zhongkechen]

Summary

• Add new OtelPlugin() for ADOT Java agent usage without handler-side GlobalOpenTelemetry initialization.
• Register OtelPluginAutoConfigurationCustomizerProvider through the OpenTelemetry Java agent autoconfigure SPI so the agent-created SdkTracerProviderBuilder gets the durable deterministic IdGenerator before the provider is built.
• Make OtelPlugin() validate that the SPI ran, then use GlobalOpenTelemetry.getTracerProvider() directly instead of creating, copying, mutating, or reflecting into a provider.
• Move the deployed X-Ray Step/Wait examples off the old ADOT collector assumption and onto the same Java-agent extension setup as the default-constructor example.
• Package the OTel plugin jar into the examples artifact under lib/ and generate SAM config that points OTEL_JAVAAGENT_EXTENSIONS / otel.javaagent.extensions at that jar for examples that use new OtelPlugin().

How It Works Now

• The ADOT Lambda layer starts the Java process through /opt/otel-instrument.
• The generated template configures the extension path as /var/task/lib/aws-durable-execution-sdk-java-plugin-otel-<version>.jar for no-arg OTel examples.
• The Java agent loads the plugin jar as an extension and discovers META-INF/services/io.opentelemetry.sdk.autoconfigure.spi.AutoConfigurationCustomizerProvider.
• OtelPluginAutoConfigurationCustomizerProvider installs a shared DeterministicIdGenerator on the agent SDK builder and marks installation through dependency-free shared state.
• OtelPlugin() checks that marker, uses the existing global tracer provider, and keeps a separate DeterministicIdGenerator instance only to publish durable execution state through system properties. The agent-installed generator reads that state when spans are started, which works across the app and agent classloader split.

Why Not Reflection

• ADOT exposes Java agent wrapper providers such as ApplicationTracerProvider14, not a stable public SdkTracerProviderBuilder surface.
• Reflection paths were brittle across OpenTelemetry versions: some wrappers do not expose unobfuscate(), and internal fields such as agentTracerProvider are not consistently visible or typed from the application classloader.
• Even when an SDK provider can be reached, replacing the ID generator after the provider is already built is not a supported contract and depends on private SDK internals.
• The SPI runs at the right lifecycle point, before the agent builds the SDK provider, and is the documented OpenTelemetry Java agent extension mechanism.

Testing

• mvn -pl otel-plugin,examples spotless:apply
• mvn -pl examples spotless:apply
• python3 generate-template.py
• mvn -pl otel-plugin -am test
• mvn -pl examples -am -Dtest="OtelXRayStepExampleTest,OtelXRayWaitExampleTest,OtelXRayExamplesTest" -Dsurefire.failIfNoSpecifiedTests=false test
• mvn -pl examples -am package -DskipTests
• Verified the examples artifact contains lib/aws-durable-execution-sdk-java-plugin-otel-2.1.1-SNAPSHOT.jar and that nested jar contains the autoconfigure SPI service entry.
• Verified the default-constructor example runs in Lambda with the ADOT layer and plugin jar extension path.

[SilanHe]

We'll have to add an integration test example where we use the optimized ADOT layer so that we can ensure this is working