Runtime muzzle agent caching is happening for ignored classloaders

[robododge]

Describe the bug
The classloaders specified to be ignored in GlobalIgnoredTypesConfigurer.java
are still considered during the muzzle runtime per-classloader checking.

Steps to reproduce
Edit the GlobalIgnoredTypesConfigurer.java add the following to ignore the janino classloader.ignoreClassLoader("org.codehaus.janino.ByteArrayClassLoader")

Since Janino is a inline compiler, push a inline script into it like this This example, it will create a new instance of its classloader, org.codehaus.janino.ByteArrayClassLoader, and proceed to generate and load a new java class. Bytebuddy will want to transform this new class and thus the muzzle AgentCachingPoolStrategy will engage adding a new WeakKey entry for this classloader. You can see the keys showing through java heap analysis

What did you expect to see?
No interaction by ByteBuddy related to ignored classloaders

What did you see instead?
An entry for each of the janino classloaders created sometime during runtime, in this case 1160 of them. These entries end up in the cache maintained by the io.opentelemetry.javaagent.tooling.muzzle.AgentCachingPoolStrategy and not get collected

What version are you using?
v1.13.1, v1.21.0 (Confirmed in these versions)

Environment
Compiler: AdoptOpenJDK 8.0.352+8, Oracle java build 1.8.0_321-b3
OS: Redhat Linux, MacOS
Runtime: AdoptOpenJDK 8.0.352+8, Oracle java build 1.8.0_321-b3

Additional context
This may not sound like a big deal, but it can balloon out because these types of classloaders are created at runtime, and if you have infrastructure that creates classloaders in this way, the first-pass AgentCahcingPoolStrategy caching will continue to stack up the weak keys and not even the cache cleaning background thread will collect these as was done in #6240

PR will be forthcoming to ignore org.codehaus.janino.ByteArrayClassLoader as a class loader

[tylerbenson]

Classes that belong to ignored classloaders must still go through the TypeDescription cache since TypeDescription instances are what the ignores matcher evaluation operates on. (See IgnoredTypesMatcher's method signature.)

Adding those classloaders to the ignore will help reduce the overhead of deeper evaluation, but to limit the impact of the cache size growth, we need to put a limit on the cache as I mentioned in #7678.

[robododge]

I'm closing this issue, it was fixed directly for the janino case by #7710

[tylerbenson]

Thanks for reporting back!