Make the invokedynamic instrumentation approach the default

[JonasKunz]

We want to make the invokedynamic-based instrumentation approach the default one eventually.
To get there, a first step will be to change the default of otel.javaagent.experimental.indy from false to true.
This will allow us to evaluate the approach in a safe (opt-out) manner in the field and fixing bugs before fully removing inlined-advice to gain the full benefits, including the removal of shading from the agent.

API features to promote

With the completion #11457, we'll have all our instrumentation capable of working with invokedynamic.
In order to change the default of otel.javaagent.experimental.indy to true, we need to make sure to also have a clean plugin interface with indy-support. Currently, those features live in the ExperimentalInstrumentationModule class.
We'll need to clean up and migrate the relevant features to InstrumentationModule:
In order to make the

• Promote injectClasses(ClassInjector)
• Replace injectedClassNames with a method on ClassInjector instead
• Promote the module-opening mechanism added via make rmi instrumentation indy-compatible + add module opener #12585

The following two features I'm not sure about whether we want to actually have them in the public API or whether we'll keep them for internal modules only:

API features not to promote

getModuleGroup

getModuleGroup(): This feature was added to ease the conversion of some instrumentations which are tightly coupled by accessing classes from each other directly. A cleaner approach for this requirement is to have:

• A shared API-project for those instrumentations which is loaded by the agent-classloader (=non-helper classes)
• Have the individual instrumentations communicate through that API-layer instead

This would involve a very big refactor for our existing instrumentations, but I don't feel like this is the case for external instrumentations. Therefore I think it would be better in terms of "best-practices" to not have this method part of the public API to promote the correct way of doing things. Maybe we could rewrite one of the internal modules (after inlining is not supported anymore) to showcase how to do this.

agentPackagesToHide

agentPackagesToHide(): This method is used when trying to instrument classes which are also present in the agent-classloader: The problem is that for linking, classes found in the agent classloader take precedence over classes from the instrumented classloader. This means that if the classes are present in both, the instrumentation won't be able to actually use/instrument them. I feel like this is an esoteric edge which should not be exposed to the public api in order to keep it simpler, as it should be very rare to stumble across.

An example where this is needed internally is the instrumentation of the opentelemetry-api: The instrumentation needs to bridge application opentelemetry-APIs, while at the same timing bringing it's own opentelemetry-API version (eventually unshaded).

Advice source code migration

For instrumentations to work with indy, the advice code needs to be written slightly differently, as described in the guide. This is currently done automatically for most advices at runtime via a runtime transformation of the advice bytecode. This of course is not ideal from a maintenance perspective, as the source-code doesn't match what is actually executed.

I'd suggest to do the following:

• Rewrite all the instrumentation advice code to no require the runtime transformation anymore (aka apply the guide)
  • Only exception: Keep inlined = true (which is the default): All other changes are backwards compatible and allow us to still run with otel.javaagent.experimental.indy=false
  • Once we remove support for inlined advice, we can add inlined = false, which is an easy, IDE-supported change (e.g. IntelliJ structural replace feature)
  • I'll try to provide an automated tool to do the more complex sourcecode-transformation (e.g. instering @Advice.AssignReturned) based on javaparser a tool for AST-based, structural code modification with a lexically preserving printer (e.g. original comments and whitespace are preserved)
• We can then disable the AdviceTransformer for instrumentations shipped with the agent. For external instrumentations, we can keep it around for some grace period and print a warning (e.g. Please migrate your advices, here is a link to our guide).

However, all of these things IMO are not a blocker for changing the default of otel.javaagent.experimental.indy to true, I'd only consider them as blockers for removing the support for inlined-advices all together.