When ServerDiscoveryMonitor::requestImmediateCheck is called, in some cases, we attempt to cancel the outstanding hello request and reschedule a new one.

Cancelling the previous request uses a CallbackHandle object that is set after scheduling the request, which happens after a delay.

This means the following sequence of events could occur:

1. A call to ServerDiscoveryMonitor::requestImmediateCheck occurs, which calls _scheduleNextHello
2. The task it schedules to do the exhaust command hangs before actually scheduling the command and setting the callback handle.
3. A new call to requestImmediateCheck arrives. It tries to cancel the outstanding request, but the callback handle hasn't actually been set yet.
4. The first request continues, setting the callback handle, which may or may not overwrite the existing one. Either way we end up with two concurrent exhaust commands running for the same host, one of which is no longer tracked or cancellable.