An operation can deadlock if it holds a CollectionShardingRuntime (CSR) or DatabaseShardingRuntime (DSR) lock while waiting for work that needs the same lock. Usually we only find about this with a BF or a HELP ticket.

We should add runtime checks, possibly similar to Locker::setAssertOnLockAttempt:

• Track CSR/DSR locks held by each operation through the scoped RAII types.
• Check before blocking work: lock acquisition, read-concern waits, DBDirectClient calls, remote command waits, interruptible condition waits, sleeps...
• (Optionally) Check before acquiring CSR/DSR locks to detect same-lock re-entry and invalid lock order.
• Allow narrow exemptions with a RAII object with a required justification.