In addition to the current single-threaded execution, test/model should have the ability to execute workloads concurrently. Note that this should be in addition to the current approach, which executes the workload serially.

Suggestion:

• Have a set number of worker threads.
• Keep a list of which operations or sequences of operations (such as transactions) are allowed to run next given their dependencies. Maybe this should
• Let each worker thread pick next task.
• Ensure proper synchronization between tasks esp. for operations such as rollback_to_stable.

Ideally, this would be possible while keeping the same workload file format.

Additionally:

• Implement a sleep (or delay) operation which would be a no-op in the model, but in WT, it would sleep for the given number of milliseconds to promote more races. Make sure to do this especially after executing prepare_transaction.
• Add the ability to run the same workload several times, as each may give us somewhat different operation interleaving. Make sure to run each workload many times during counterexample reduction, as only some interleavings may trigger a test failure.

At this point, ensure that the resulting database state is deterministic by being intentional about at which point in the workload execution the runner restarts or crashes WiredTiger. We will relax this in WT-11627.