Avoid leaking plugin classes into Gradle's pattern spec result cache

[mark-vieira]

This pull request fixes some memory leak issues we noticed when using the Shadow plugin with long lived Gradle daemons. The commit addresses two items:

1. RelativeArchivePath was unnecessarily keeping a reference to DefaultFileCopyDetails which is a pretty heavyweight object. Turns out this is never actually used so this has been removed.

2. The whole reason item (1) was an issue was is because results of calls to pattern specs are actually cached by Gradle, such as this one. The cache computes a key based on this RelativeArchivePath, therefore instances of those stay in memory. Making those instances lighter (by removing the reference to FileCopyDetails) helps here but the root cause is that the daemon keeps strong references back to plugin classes, and therefore, their classloader. When changes to buildSrc happen these old classloaders pile up, as we cannot garbage collect them due to these cache references. The solution here is to not use non-core types in these caches at all, thus the addition of getAsFileTreeElement() to ArchiveFileTreeElement. This avoids the need to pass ArchiveFileTreeElement directly to isSatisfiedBy() and thereby ensuring no classes from this plugin leak into the pattern set result caches.

[johnrengelman]

Thank you for the digging into this and providing the fix @mark-vieira !

[johnrengelman]

This fix is now available in 4.0.3

[mark-vieira]

Awesome. Thanks for the quick turnaround.