Spike: Explore ways to eliminate requiring the OTel SDK as a dependency for customers

[jasonjkeller]

Our current hybrid agent prototype relies on the OTel SDK classes being present to work. If they are not present then we will not instrument the SDK to do auto-configuration and trigger NR tracer creation. https://github.com/newrelic/newrelic-java-agent/tree/main/instrumentation/opentelemetry-sdk-extension-autoconfigure-1.28.0

This means that if a customer is using OTel custom instrumentation, OTel standalone library instrumentation, or OTel native instrumentation they must also explicitly add the OTel SDK as an application dependency so that our instrumentation gets triggered by the OTel instrumentation. Also, when using the OTel Java agent with it's no-code (bytecode/invoke dynamic instrumentation) it does not expose the SDK classes such that they would trigger the NR Java agent if it was running at the same time.

While requiring the OTel SDK is not a huge deal, it could make for a more seamless experience if the NR Java agent instead detected the usage of OTel APIs and provided its own backing of the OTel SDK. This is effectively what the OTel Java agent does and some NR APM agents have figured out how to do the same (e.g. .NET agent). We should explore the feasibility of this with the NR Java agent.

[workato-integration]

https://new-relic.atlassian.net/browse/NR-362943