We should extend the work from SERVER-30681 to use a readPreference of "secondary" in order to gain testing coverage of the "Secondaries chunk aware" project. When {sharding: {enabled: true}} is used as the cluster options, then the collections prepared by the concurrency framework are automatically sharded (typically using an {_id: "hashed"} shard key).

if (args.sessionOptions !== undefined) {
    // Start session
    myDB = ...

    if (args.sessionOptions.causallyConsistentReads) {
        // TODO SERVER-30679: We manually enable causal consistency on the connection object so that
        // "afterClusterTime" is injected into the readConcern of any command requests through this
        // connection.
        myDB.getMongo().setCausalConsistency();
        myDB.getMongo().setReadPref("secondary");
    }
}

Note: FSM workloads that use a unique collection or database name in order to avoid highly-destructive actions for other FSM workloads won't use a sharded collection. Additionally, FSM workloads that drop the collection or database as part of their state functions won't re-create the collection as a sharded collection. We should try experimenting with implicitly_shard_accessed_collections.js override to automatically create (or re-create) the collection as a sharded collection in these cases. It's possible that similar to the sharded_collections_jscore_passthrough.yml test suite, some FSM workloads may have internal assertions or invariants that get violated if a collection was known to have been dropped by an FSM worker thread comes back on its own.