tree bc77d28423c46037ce9d78e28f78b17c76f67eae
parent 7d61c6ff9256896fb8304295ebf3e6d69f64c6a2
author Dariusz Luksza <dariusz.luksza@gmail.com> 1713886767 +0100
committer Dariusz Luksza <dariusz.luksza@gmail.com> 1715433290 +0100

Decouple thread pool from event handler

Currently handling each event will result in a single thread
`ExecutorService` being created to use
`CompletableFuture.runAsync` on it. What's more, each
`EventListenerHandler` will add a JVM shutdown hook, which will later
prevent that instance from being GC'ed and lead to slow memory build-up
on the system.

To prevent memory leakage we extract the thread pool into the
`EventHandlerExecutor` class plus we register a `LifecycleListener` in
form of `PluginLifecycleListener` to register and unregister JVM
shutdown hook, and stop the thread pool when the plugin is unloaded.

The `EventListenerHandler` is also renamed to `EventHandlerTask` and
stays mostly unchanged.

This refactoring has one side effect, we cannot rely on the
`SingletonManager` in tests, as the singleton instance for change will
be unregistered by the `EventHandlerExecutor` before we can even access
it. To fix this a follow-up change will be provided to replace
`SingletonManger` with Guice scope.

Change-Id: If9422a4449311682958173901b438dd847e69acb