Force cleanup of ThreadLocal

[WolfgangHG]

This problem was found as part of arquillian/arquillian-extension-warp#131 - full details see there.

"arquillian-extension-warp" initializes an Arquillian "Manager" in a javax.servlet.Filter implementation.
When running on a GlassFish server, the Filter init method is called on a different thread than destroy, where "Manager.shutdown" is called. This causes ThreadLocal leaks.

This results in a lot of warnings in GlassFish console:

[#|2023-05-19T22:47:20.542+0200|SEVERE|glassfish 4.1|javax.enterprise.web.util|_ThreadID=49;_ThreadName=admin-listener(5);_TimeMillis=1684529240542;_LevelValue=1000;|
  The web application [/test] created a ThreadLocal with key of type [org.jboss.arquillian.core.impl.ManagerImpl$1] (value [org.jboss.arquillian.core.impl.ManagerImpl$1@1310e023]) and a value of type [java.util.HashSet] (value [[]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.|#]
[#|2023-05-19T22:47:20.542+0200|SEVERE|glassfish 4.1|javax.enterprise.web.util|_ThreadID=49;_ThreadName=admin-listener(5);_TimeMillis=1684529240542;_LevelValue=1000;|
  The web application [/test] created a ThreadLocal with key of type [org.jboss.arquillian.core.spi.context.AbstractContext$1] (value [org.jboss.arquillian.core.spi.context.AbstractContext$1@49cc8b9c]) and a value of type [java.util.Stack] (value [[]]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak.|#]

The ThreadLocal variables are in org.jboss.arquillian.core.impl.ManagerImpl and org.jboss.arquillian.core.spi.context.AbstractContext.
Creating the ManagerImpl creates ThreadLocal entries that cannot be removed later. And I don't have enough Arquillian knowledge to decide whether the implementation could be changed not to write data to the ThreadLocal variables.

So I followed this article to force ThreadLocal cleanup by using reflection: https://stackoverflow.com/questions/3869026/how-to-clean-up-threadlocals

On GlassFish, this mainly avoids warning messages.

But besides one less warning, the cleanup brings a real improvement: I can reproduce an OutOfMemoryException when running the test suite of "arquillian-extension-warp" several times against a remote WildFly server without restarting it (about 5-7 turns). After testing with my ThreadLocal workaround, I did not observe this error after 20 test runs. So it seems to really have a positive effect.

[WolfgangHG]

I kindly want to ask for an update. Any chance to get this merged? Or is there a better way handle this in arquillian-extension-warp?

I ping @starksm64 as you merged my previous pull request, and @chengfang a you were involved in the initial discussion in arquillian-extension-warp.