MemoryLeak in TargetCacheImpl_DataApps

[benjamin-confino]

Describe the bug
TargetCacheImpl_DataApps has a WeakHashMap<String, TargetCacheImpl_DataApp>().

In the method getAppForcing we populate the map using apps.put(appName, app);. app is a TargetCacheImpl_DataApp

TargetCacheImpl_DataApp also takes an appName parameter. The same string is both inside used as the key, and stored inside the value so this will never release. I've also been informed that ensuring app uses a copy of the string causes even worse problems.

(I would like to give credit to Jared Anderson, he found out the details in the previous paragraph and left a helpful slack message that saved me the trouble of doing so. Apologies if there is an issue for this already, I didn't find one)

Steps to Reproduce
Running io.openliberty.microprofile.rest.client.4.0.internal_fat_tck is a good way to get a liberty server leak a lot of memory.

Expected behavior
TargetCacheImpl_DataApp's weak hash map's entries are garbage collected when an app is shut down.

[benjamin-confino]

I was able to make a quick dirty prototype that resolves this leak, by creating a listener for metadata created/destroyed events that creates object warppers around string names to use as keys in TargetCacheImpl_DataApp

The key must be the name of the application, which in turn must be the deploymentName from com.ibm.ws.container.service.app.deploy.ApplicationInfo (we have to many values for app names)