During FCV upgrade setFCV can end up logging operations in <db>.system.profile even if <db> does not have profiling enabled. This happens because the CurOp of the setFCV OperationContext becomes dirty from the collMods that setFCV runs (for example, over all collections to clean up invalid index options) such that the profiling level and the NSS is a mixup of the state of multiple DBs.

This is a re-ocurrence (regression) of SERVER-85925.

This can happens as follows:

• The user enables profiling on DB "test" only.
• The user creates collection "test.somecollection".
• The user calls setFCV to upgrade the FCV.
• setFCV it runs collMod on "test.somecollection":
  • This runs on the OperationContext from setFCV.
  • This creates an AutoStatsTracker as part of the collMod.
  • This will raise the dbprofilelevel on the CurOp.
  • When collMod finishes the CurOp remains with the raised profiling level.
• setFCV runs collMod on "config.whatever":
  • This runs on the same OpCtx as before.
  • The "config.whatever" NSS gets set on the CurOp.
  • The dbprofilelevel is still raised from the previous collMod on "test.somecollection".
• When the command ends, in the Service Entry Point:
  • It will see that the CurOp NSS is "config.whatever"
  • The CurOp dbprofilelevel is enabled.
  • Therefore, if setFCV took more than 100ms it will log on "config.system.profile" despite profiling not being on "config".

A reproducer is attached.

We should prevent the CurOp of setFCV from getting dirty from any sub-operations it calls.