Currently, the `AuthzLockGuard` class is used to synchronize user management commands on the server. It has two modes: Read and Invalidate, where the latter prompts the guard to invalidate the user cache when it goes out of scope. Effectively, the guard ensures that only one UMC can run at a time, which was necessary to ensure that role information could not be changed by another UMC when resolving a user's roles.

Now that the server supports transactions, it may be possible to eliminate this lock and instead construct transactions for each UMC. This should ensure that we are able to defer locking strictly to the database queries that comprise the transaction. Some UMC's (`dropRole`, `dropAllRolesFromDatabase`) already use transactions, but others (usersInfo) still need to be changed for this to occur.

If it turns out that the server still needs `AuthzLockGuard` in some capacity and cannot fully replace it with transactions, then it can still be improved by turning it into a readers-writer lock. The current implementation only permits a single `usersInfo` or `rolesInfo` command to run at a time, while theoretically any number of those read-only commands should be permitted to run in parallel. This can actually create a noticeable performance boost on config servers in sharded deployments, which typically run `usersInfo` when authorizing users when both the mongos cache and its own cache miss. 

Although this ticket is suggested as a general performance improvement, it may directly help alleviate BF-23039.