During the implementation of SPM-4061, specifically SERVER-127230, we introduced a new option in the ShardingCoordinator infrastructure so that makeOperationContext() can return a CancelableOperationContext backed by the PrimaryOnlyService abort-or-stepdown token. This behavior is controlled by the new virtual method ShardingCoordinator::_shouldUseCancelableOpCtx(), and it is currently enabled only by MoveRangeCoordinator.

In theory, there is no need to link the POS cancel token to the coordinator operation contexts because all operation contexts created by the ShardingCoordinator are already being cancelled via different ways:

• All OperationContexts created on a PrimaryOnlyService should be implicitly marked as interruptible.
• Additionally, all OperationContexts should be killed by the PrimaryOnlyService when the service gets interrupted.

During the implementation of SPM-4061, and due to the urgency of that work, we did not have time to determine whether this option was actually needed for MoveRangeCoordinator. We shipped the change and postponed the investigation.

The goal of this task is to figure out if we should keep the option of creating a cancelable OperationContext linked to the POS cancel token. If the answer is no, we should clean up the ShardingCoordinator interface by:

• removing the method _shouldUseCancelableOpCtx() 

• making method makeOperationContextmakeOperationContext() return a normal OperationContext instead of a CancelableOperationContext.