Because we store the operations that are waiting for a connection from the pool as a std::vector<TaskExecutor::CallbackHandle>, we need to do an O(n) scan to remove it when we move it to the _inProgressMap.

Under load (10's of thousands of concurrent ops) the cost of traversing this vector dominates the total time of an operation. This has been verified by profiling with the linux perf utility, the output of which is attached to this ticket.

To remedy this, we should make CallbackHandles hashable so that we can use a better data structure with O(1) insert/removal.