This pull request makes some changes to HelperInjector to reduce memory usage, increase performance, and decrease the chance of deadlocks.

Removes helperMap to save memory

The helperMap was an injector-local cache of the byte[] representation of an instrumentation's helper classes. Since each instrumentation has its own HelperInjector, each instrumentation had its own helperMap. These arrays were never reclaimable by GC.

The performance impact of removing this cache should be negligible because:

• the helper classes are still only loaded once per target classloader
• the DatadogClassloader has its own internal class cache

Module logic improvement

There is only one unnamed module per classloader. The new code takes advantage of this fact.

Removes synchronization block

Internally, bytebuddy locks the classloader being injected. The synchronization block meant there was potential for deadlock:

• Thread A: Has HelperInjector lock, is waiting for Classloader lock
• Thread B: Has Classloader lock, is waiting for HelperInjector lock

While unlikely because of when injection usually happens, it was still possible. Additionally, synchronization was only necessary because of the HelperMap caching. As the cache was removed, synchronization could also be removed.

Using injectRaw() instead of inject()

Internal to ByteBuddy, inject() calls injectRaw by copying the classmap. Unintentionally, some instrumentation code paths converted this map 3-4 times. Using injectRaw() avoids this problem.