On mongoS, we use the RouterExecStage::ExecContext enum to allow a tailable awaitData cursor to determine whether it should wait for further input. But on mongoD, we use the AwaitDataState struct to perform the same task. We already use part of this struct on mongoS to track how long we should wait for more input, but we do not currently use AwaitDataState::shouldWaitForInserts to signal to the execution machinery that we should wait in the first place. There does not seem to be any reason to keep RouterExecStage::ExecContext - which must be plumbed through the entire execution tree down to the BlockingResultsMerger - instead of just using AwaitDataState::shouldWaitForInserts in the same way as we do on mongoD.