STASHDEV-7788 Change `BasicOperationScheduler.responseThread` from a sin...

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.
I'm not sure what you're talking about, at this point. I never said anything about changing Hazelcast, nor did I raise any objections about their architecture. _You_ added this array, which is what I'm objecting to, and replacing _this array_ with an `ExecutorService` doesn't require any changes to Hazelcast's architecture. They never had multiple threads here in the first place, so whether those additional threads are added using an array or an `ExecutorService` seems to be unrelated to any of their other architecture.

When a new task is submitted to an `ExecutorService` which still have room to grow and the existing threads are all busy, a new thread is added. So ensuring work is "never held up when there are idle cores" is true either way. When the pool is full, work will be "spread out over the available cores" just as well by an `ExecutorService` as it is by an array. The difference is that when the system is _idle_ it won't have dozens of extra threads doing nothing. Threads aren't only not free to start; they're also not free to _keep running_. They're increased contention on the task queue, and their stacks are a fixed memory cost we pay even when they're idle.