There have been numerous cases where the concurrency* tasks time out on our OS X, ARM, and DEBUG builders because the machines are making slow progress. Since the fsm_all*.js tests actually runs other tests—namely the FSM workloads defined in the jstests/concurrency/fsm_workloads/ directory—it doesn't make sense to expect we'd be able finish running all of those tests within 2 hours. We should set the timeout_secs for the "run tests" function in the concurrency* tasks to 6 hours to work around how resmoke.py won't produce output until all of the FSM workloads have finished. This effectively corresponds to running the concurrency* task with only a exec_timeout_secs (default=6 hours) set. A separate project will be scheduled in the future to better integrate resmoke.py and the concurrency suite together so each FSM workload is recorded as a separate test case.

We should also consider increasing the exec_timeout_secs of the concurrency_sharded* tasks to 12 hours because they run both fsm_all_sharded_replication.js and fsm_all_sharded_replication_with_balancer.js. This would help to avoid issues from running the concurrency_sharded_WT with --repeat=10 on the "Linux Repeated Execution" builder.