OF-3208: Fix plugin unload failure on Windows caused by JVM file locks
On Windows, the JVM holds mandatory file locks on JAR/class files opened by a plugin's class loader. These locks are not released until the underlying ZipFile/JarFile handles are garbage-collected, which prevented the extracted plugin directory from being deleted during unload. Because the cleanup of internal data structures (pluginsLoaded, childPluginMap, parentPluginMap) was sequenced after directory deletion, isLoaded() would incorrectly return true for plugins that had been unloaded, causing testDelete_Node_A and testReload_Node_A to fail on Windows CI.
Changes:
- Move pluginsLoaded/childPluginMap/parentPluginMap removal to immediately after doDestroyClassLoader, so that isLoaded() reflects logical state regardless of whether physical file deletion succeeds.
- Add System.runFinalization() alongside the existing System.gc() hints in doDestroyExtractedFiles to improve the likelihood of lock release between deletion attempts. Note: System.runFinalization() is deprecated since Java 18 and will need to be removed when support for it is dropped.
- Register all remaining files and directories with File.deleteOnExit() if the extracted plugin directory still exists after all retry attempts.
OF-3211: Make plugin directory destruction timeout configurable
This commit introduces two properties, without changing its default values.
- `plugins.unloading.directory.destroy.delay` (2 seconds) - A delay that is observed between the time a plugin's unloading starts, and the plugin directory actually being removed.
- `plugins.unloading.directory.destroy.timeout` (40 seconds) - The maximum time that Openfire will wait for a plugin directory to be destroyed after the plugin is unloaded.
Instead of iterating 5 times up until the destroy timeout, the code now iterates more frequently. This should give faster response times in cases where the plugin directory destruction was successful only moments after the initial iteration failed.
Unit tests have been modified to reduce these values during their runtime. This is expected to reduce the runtime of tests.
OF-3209: Introduce more reliable flag to signal plugin reload
Previously, a plugin was marked to be reloaded by having its 'last modified' date reset. This is an operation that's not guaranteed to be successful on all operating systems. In this commit, a more explicit flag is used.
OF-3209: Fix plugin unload/reload failures on Windows caused by orphaned directories
On Windows, mandatory JVM file locks can prevent the extracted plugin directory from being deleted during unload. This causes two problems:
1. A deleted plugin whose JAR is gone may be reloaded from its orphaned directory. Fixed by filtering the directory stream to skip directories without a corresponding JAR/WAR file.
2. A reloaded plugin may be re-extracted from a stale directory if the previous directory deletion failed. Fixed by comparing JAR and directory modification times in unzipPlugin, forcing re-extraction when the JAR is newer than the existing directory.
Resolves test failures in PluginLoadingSimpleHierarchyTest and PluginLoadingComplexHierarchyTest on Windows.
OF-3209: More reliably test if plugin got reloaded
This modifies a unit test to no longer determine based on file attributes (last modified timestamp) if a plugin got (re)loaded. These attributes are not reliably set on all operating systems. The new approach registers an event listener instead.
