The concurrency framework uses ScopedThread in worker_thread.js to run a single copy of an FSM workload against the MongoDB deployment. Each FSM worker thread has its own connection to the cluster. We should configure the connections that the FSM worker threads use to start a new session with specific options.

• The "sessionOptions" key should be added as a valid execution option. The validateExecutionOptions() function should be updated accordingly.
• The executionOptions.sessionOptions object should be specified to the workerThread.main() function as part of the args.sessionOptions parameter. The args object constructed in the ThreadManager#spawnAll() function should be updated accordingly.
• The FSM worker thread should call Mongo.prototype.startSession() with args.sessionOptions if args.sessionOptions !== undefined. The myDB variable in the workerThread.main() function should be updated accordingly.

Note: While the changes should be tested locally and in an Evergreen patch build with something a patch similar to the following, the actual work to add new resmoke.py YAML suites and Evergreen tasks for running under this configuration will happen under a follow-up SERVER ticket.

diff --git a/jstests/concurrency/fsm_all_sharded_replication.js b/jstests/concurrency/fsm_all_sharded_replication.js
index 66de8c45ff..7d272412ea 100644
--- a/jstests/concurrency/fsm_all_sharded_replication.js
+++ b/jstests/concurrency/fsm_all_sharded_replication.js
@@ -99,4 +99,5 @@ var blacklist = [
 runWorkloadsSerially(ls(dir).filter(function(file) {
     return !Array.contains(blacklist, file);
 }),
-                     {sharded: {enabled: true}, replication: {enabled: true}});
+                     {sharded: {enabled: true}, replication: {enabled: true}},
+                     {sessionOptions: {}});