Support testing library/agent instrumentation interoperability

[trask]

I don't think the removed code is needed anymore since the library instrumentation is shaded inside of the agent even during tests now. But let's see what CI says...

Removing this code will allow agent tests to be written that use the library instrumentation and verify interoperability between the two.

[anuraaga]

@trask Looks like CI might not like this PR, but also the tests not catching #4718 makes me think that either an improvement or alternative to this snippet is still needed

[anuraaga]

@trask Thanks for looking at this :) By the way, the idea I had in mind to remove this snippet and make things hopefully more robust is a custom configuration type for instrumentation dependencies we bundle. We currently have library, which is like compileOnly + testImplementation (with the ability to raise the version number to latest), we could have a bundled which is like compileOnly + shadowInclude (semantically, we don't shade each individual project so this configuration would need to be recognized at the bundle site). And this would then make sure the files aren't in the test classpath in a more Gradle-native way than my hack around our current usage of implementation

[trask]

the idea I had in mind to remove this snippet and make things hopefully more robust is a custom configuration type for instrumentation dependencies we bundle. We currently have library, which is like compileOnly + testImplementation (with the ability to raise the version number to latest), we could have a bundled which is like compileOnly + shadowInclude (semantically, we don't shade each individual project so this configuration would need to be recognized at the bundle site). And this would then make sure the files aren't in the test classpath in a more Gradle-native way than my hack around our current usage of implementation

This sounds cool, though I'll probably leave this part for the gradle magicians ✨

I think I've about worked out what should / should not be on the class path in order to enable writing tests that verify interoperability between agent and library instrumentation (see also #4779).

[trask]

CI still hasn't passed yet, but I'm feeling good about this next run, so optimistically marking it ready for review 😂

[iNikem]

If lib is an absoluteFile, how can it start with opentelemetry-javaagent?

[trask]

it's lib.name, e.g. File.getName(), not the full path