After SERVER-56879, DDL operations can take longer when executing with concurrent add/removeShard, especially in the presence of long-running DDL operations such as reshardCollection. This is compounded with a queuing issue caused by checkMetadataConsistency, which takes an S lock on databases, causing any DDL operation to queue behind it while waiting for a running DDL to release an IX lock. In *_with_config_transitions, which run a lot of add/removeShard operations, this is causing some tests to trip timeout limits. The goal of this task is to set reshardingMinimumOperationDurationMillis to 0 in those suites to alleviate some of that contention (default value is 5 seconds).