In SERVER-99150 we've implemented a lock ordering checker for debug builds. As a result we discovered that there is a lock ordering conflict in the ShardServerOpObserver.

Normal operations that use the preimages featurre take the following lock ordering based on their op observer:

• Lock target db
• Lock collection
• Lock config db
• Lock inner config collection

However, the ShardServerOpObbser takes the following lock ordering during replication:

• Lock config db
• Lock inner config collection
• Lock db extracted from the modified document
• Lock collection

As a result we have two lock orderings:

• user database -> config
• config -> user database

As the locks taken for the config database are intent locks this shouldn't matter too much as there's no deadlock possible but we still should investigate if the lock ordering can be fixed.