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.
That reasoning isn't very strong for me. If the system is under enough load that creating threads would hurt it chances are better than good that the thread pool will already be at maximum size and will stay there. If the system has load spikes, though, an executor will be able to adapt to it. This puts the full allotment in place all the time.

Given that we're shipping the _standalone_ product built on this I think this is way overkill. I think the only reason they allocate arrays of threads in other places is that those things _must_ be fixed size because they deal with objects which have thread affinity, like locks.