We should be able to gain further coverage of transactions when operations are happening on the database concurrently by leveraging the existing FSM workloads.

Unlike the replica_sets_multi_stmt_txn_jscore_passthrough.yml test suite, it will be possible (and in some cases very probable) for operations to trigger a write conflict once run inside of a transaction. robert.guo proposed the idea of retrying a single state function's execution until the transaction commits. In order to make this approach compatible with an arbitrary FSM workload, we'll need to make a copy of the args.data object before the state function is called. This ensures a subsequent execution of the state function when the transaction aborts doesn't (speculatively) contain the effects of the aborted transaction. The args.data object should be reassigned to the possibly mutated value if the transactions commits.