STASHDEV-7788 Change `BasicOperationScheduler.responseThread` from a singleton thread into a small thread pool.
This is intended to alleviate the observed bottleneck where (according to `HealthMonitor` stats on one of our
production instances) `executor.q.response.size` and `operations.remote.size` keep growing under heavy load.
STASHDEV-7788 Monitor a few extra statistics in the `HealthMonitor` logging

 * `lock.count` which is the number of in-flight lock operations
 * `executor.q.response.stats` consisting of:
    - number of responses processed since last log
    - cumulative deserialisation time (nanosec resolution) since last log
    - the single worst packet in terms of deserialisation time since last log

The intention is to find out why the `responseThread` is getting stuck.
Deserialisation should be super quick, right?
Merge branch 'STASHDEV-7788-moar-health-monitoring' into atlassian-3.x-integration
Merge branch 'atlassian-3.x-integration' of https://github.com/atlassian/hazelcast into atlassian-3.x-integration
STASHDEV-7788 Wait for the `responseThread`s to terminate on shutdown.
Revert "Merge branch 'STASHDEV-7788-moar-health-monitoring' into atlassian-3.x-integration"

This reverts commit 88f0e3df8142e7dc794f2fe94e0a6b8ef2a3c832, reversing
changes made to 54e213807aa1c422fe56fecb20d2ec9889bcedbe.
STASHDEV-7788 Include response thread count in JMX monitoring
STASHDEV-7788 Reduce default number of response threads from 2*cpus to 1*cpus.
Response threads do much much less work than operation threads and Hazelcast
got by with only 1 before, so 2*cpus would be overkill.
Merge pull request #3 from atlassian/STASHDEV-7788-response-thread-pool

STASHDEV-7788 Change `BasicOperationScheduler.responseThread` from a singleton thread into a small thread pool.