Hook processing can be delayed as a result of add-ons using the shared ExecutorService

A shared ScheduledExecutorService is made available for add-ons to use, and add-on developers are encouraged to use it instead of, for example, doing heavy processing directly in event listeners (which are invoked on a limited number of dispatcher threads).

However, the HookService, which handles pre-receive and post-receive callbacks from pushes is also using that shared executor. That means if add-ons invoke particularly slow/heavy operations on the shared executor, it can block pushes. The hook service should be updated to use its own executor, instead, to ensure its processing is not delayed by other parts of the system, be they built-in or provided by add-ons.

Starvation, as well as what's causing it, can be detected by taking a thread dump and looking for threads whose names start with "threadpool:thread-". By default, the system allows 1 threadpool thread per logical CPU (see Runtime.availableProcessors()).

(A note about "Affects Version/s". This possibility for add-ons to starve out hook processing has existed since support for hooks was first added in Stash 2.0. That means all 2.x, 3.x, 4.x and currently-released 5.x versions are susceptible.)