Database query improvements for fixed-size task aggregate job creation

Continuing from discussion on #658: The method read_batch_size(), used during aggregate job creation for fixed-size tasks, may create a lot of SIReadLocks when doing index scans over report_aggregations. We discussed a couple denormalizing strategies that could be useful tradeoffs: either storing the number of report aggregations in different states in the aggregation_jobs table, or storing min_size/max_size in outstanding_batches. create_aggregation_jobs_for_fixed_size_task_no_param() could also be broken up into multiple smaller transactions, if we ensure consistency with some other means, like read-modify-write or leader elections.

This is the fixed-size task counterpart of #269. (though I think the asymptotic complexity of the queries here is not an issue, compared to those in #269)

Start with read_batch_size() and create_aggregation_jobs_for_fixed_size_task_no_param(), then read the schema and query code for report_aggregations, aggregation_jobs, and outstanding_batches. Review issues #658 and #269 to understand the prior discussion; the work is not complete until a chosen strategy improves fixed-size aggregate job creation while preserving consistency.