SERVER-77507 modified DBDirectClient such that the opCtx's TransactionResources are stashed before the sub-operation is run. 

This results in a change in behavior with respect to how the sub-operation acquires locks and an execution-control ticket. Previously, a sub-operation would not queue for any locks that were already acquired by the parent or compatible with those held by the parent, as it could re-use those lock grants. Similarly a sub-operation would not acquire an additional execution ticket if the parent operation had already received one, because the locker on the opCtx would have already had a ticket. 

Importantly, the parent operation's TransactionResources are stashed, not yielded. I think this means there is a new possibility of deadlock or ticket exhaustion due to the above behavior:

1. additional concern for ticket exhaustion because re-entrant sub-operations will now use multiple storage tickets, when in previous cases they used one
2. new potential for deadlocks: for example, if the "parent" operation is holding an IX mode lock on a resource and the "child" operation tries to acquire an IS mode lock, previously, this would have immediately succeeded due to the recursive handling in the lock manager. But now the child operation will be blocked if a strong lock is enqueued in -between, and we will deadlock because the child operation will be stuck behind the strong lock acquisition which is stuck behind the parent