On a heavily loaded Beaker instance, like our production one, beakerd's scheduling routines can become a bottleneck. In particular the scheduler does a lot of work on the job and system tables, and is contending for locks with HTTP requests for in-progress jobs (recording results, etc).

To help reduce latency and eliminate lock contention as much as possible, beakerd should avoid doing any unnecessary queries. But currently each scheduling loop is structured in the form:

* count if there are rows that need attention
* if there is,
   * log a message to say I'm doing work
   * loop over the rows that need attention (this is a separate query)
       * do the work
   * log a message to say I'm done

We can eliminate the first count in favour of just iterating over the actual rows. There will be zero iterations of the loop if there is nothing to do.

One neat thing about the current approach is that it means the scheduler does not log anything if it is not doing any work, which means on a quiescent Beaker system the beakerd.log file stays quiet instead of filling with pointless spew. However I think we can just tweak the logging (specifically, ensure we log *inside* each loop iteration but not outside) to achieve roughly the same effect, while still avoiding the unnecessary COUNT() queries.