Scheduler could avoid operators with neither messages nor capabilities

In principle, the computation.step() code, which swings through each Box<Operate> recursively, has some insight into whether the operators it is about to schedule have either pending inbound messages or outstanding capabilities. The scheduler could avoid such operators, under the presumption that they cannot currently influence the rest of the dataflow. This could improve latency by moving only between operators with work to do, avoiding chit-chat with the often large numbers of operators that are currently dry.

There are some important details to double-check. For example, each call to pull_internal_progress reports a bool which means "other than messages and capabilities, do I have any other work?" which the scheduler should probably respect (it is meant for un-apparent work, like pushing data to disk, printing things to the screen, etc). This might also prevent operators from performing opportunistic work to fill empty time, unless we notice when there is nothing to do, and give everyone a slice.

Ideally, we could produce a clear explanation of when and how often operators would be scheduled. At the moment it is "once per call to step(), and if it becomes less than that, we might see some unintended consequences.

Start with computation.step() and trace how it recursively visits each Box. Read pull_internal_progress and its boolean result to understand work that is not represented by messages or capabilities. Define and document when operators are scheduled, including how opportunistic work and empty-time scheduling should behave; completion should include a clear scheduling explanation and evidence that unintended consequences are avoided.