Investigate ticket exhaustion scenarios with FLE2 usage of DBDirectClient in certain areas of code:

From blake.oler@mongodb.com 's comment in HELP-82574:

SERVER-92656 describes the same scenario as jason.chan@mongodb.com's comment above, where we have operations that are acquiring more than one execution control ticket. My linked ticket describes our being able to sidestep the situation, since using the same OperationContext and Locker instance will cause us to be able to recursively acquire the same execution control tickets. However – in oft-called FLE code, we create and use a DBDirectClient after having changed the OperationContext. A related ticket SERVER-106499 asserts that we reach this pathway after already having acquired a ticket, and my own experimentation locally confirms this case. The implication is that an FLE crud operation will attempt to acquire two execution control tickets for a single operation.

erwin.pe@mongodb.com :

blake.oler@mongodb.com and I have been testing the FLE2 pathways that can cause this DBDirectClient to end up acquiring more than one execution control ticket, and we've only ran into this problem if running an explain command with a find on an encrypted field (This issue can easily be fixed by moving the FLE2 rewrite call earlier in the explain command execution, but the root of the problem is related to lock acquisition logic in v8.0).  Since we don't hit this scenario with regular FLE2 find/aggregate commands, I think it's unlikely that the cause of the ticket exhaustion is related to the high rate of FLE2 finds that preceded the stalled periods.