In the current ShardingRecoveryService API, acquireRecoverableCriticalSectionBlockWrites tasserts if the CS is held by some thread on the same namespace and expects the caller to check. This is problematic for two reasons:

1. The caller only cares about acquiring CS and releasing it, it would need to know multiple additional APIs to check for others holding the CS.
2. The semantics of acquire/release in critical section APIs is usually block until acquire succeeds. Between checking for CS in IS mode and acquiring, there is a race and theoretically there is a starvation problem.

ShardingRecoveryService can be improved to provide additional APIs to block until acquire and consolidate waiting/signals. This would also prevent incorrect usage bugs and simplify code. Although DDL operations are serialized at ShardingDDLCoordinator, there are cases like these where acquiring CS can fail.