ShardingTest is overriden in sharding_continuous_config_stepdown.js, which ups the verbosity and lowers the electionTimeoutMillis before running the regular ShardingTest and then finally starting the periodic stepdown afterwards.

One solution is to move the lowering of electionTimeoutMillis to 5,000 ms after ShardingTest runs. ShardingTest has non-retriable writes that can fail. Stepdown due to slow machines would be much less likely with electionTimeoutMillis default of 10,000 ms.

This commit moved lowering electionTimeoutMillis to before ShardingTest runs, because electionTimeoutMillis became settable via new configReplSetTestOptions. Prior to that improvement, electionTimeoutMillis was set after ShardingTest ran. There appears to be nothing preventing electionTimeoutMillis being set after ShardingTest, aside from costing an additional write.