Futures are heavily optimized to be essentially free in the "ready already" case, but do have some overhead when chaining on a non-ready future. This code is using the slower "not-ready-yet" path for futures, even though it triggers the chain before returning. Defuturizing or at least using makeReadyFutureWith() should be an easy win. Consider reverting this revert which reintroduced the usage of the slow path in this code.

Additionally, this patch to SessionWorkflow::_scheduleNextIteration will bypass the scheduler overhead and keep running eager futures in an ordinary loop when doing sync networking.

diff --git a/src/mongo/transport/session_workflow.cpp b/src/mongo/transport/session_workflow.cpp
index 7342a707866..3ddc787deff 100644
--- a/src/mongo/transport/session_workflow.cpp
+++ b/src/mongo/transport/session_workflow.cpp
@@ -809,7 +809,10 @@ void SessionWorkflow::Impl::_scheduleIteration() try {
         }
         if (useDedicatedThread()) {
             try {
-                _doOneIteration().get();
+                while (useDedicatedThread()) {
+                    _doOneIteration().get();
+                    _work = nullptr;
+                }
                 _scheduleIteration();
             } catch (const DBException& ex) {
                 _onLoopError(ex.toStatus());

These combine to a small 2-3% improvement, which is small and hard to measure, but can be combined with other small wins to add up to something substantial. This also seems to be the "obviously better" thing to do, so there shouldn't be any controversy on this case.