Redo the control flow between SessionWorkflow's scheduleNewLoop and startNewLoop.
(Details TBD)

This is difficult to follow. scheduleNewLoop schedules startNewLoop on the executor. The last thing the startNewLoop does is a getAsync to make scheduleNewLoop happen again, so there's a loop of mutual recursion.

Both functions behave differently based on whether the current command is an exhaust command or not. This is pretty weird, because the logic is distributed and there's not a clear line of execution. The significant thing about exhaust commands is that they skip the sourceMessage step, but after that they should behave the same as non-exhaust commands.

Refactor this loop so that each "loop" sets up a Future and attaches the appropriate continuations to get a single request received, processed, and sent. That's the goal. If that "request receive" part is a no-op, then the Future chain will be a little different. That's fine. The important thing is that we unify the exhaust-non-exhaust paths and get a clear linear execution that can be read off in the source code.