Optimize model run listing

[zachmullen]

• Remove unnecessary aliases
• Remove ground truth aggregate computation and rely on ModelRun's ground_truth field instead
• Short-circuit matching Region lookup (not in hot path)
• Remove caching infrastructure since this branch should obviate it
• Add denormalized fields to ModelRun for caching expensive summary statistics
• Add method to compute the new fields on a single ModelRun
• Add function to compute the new fields on all ModelRuns (mostly for use during migration)
• Call computation function in all places where data might change

[zachmullen]

As of 8d72baf, total response time of all queries for the model run listing endpoint is down to tens of ms:

Quite a few further optimizations are possible.

• We only need to compute the aggregate bounding box and time range when filters change, not when a new page of results is requested.
• We could also cache the properties of model runs that require joins/subqueries against other model runs, but that would likely require much more complicated invalidation logic. If the cardinality of model runs stays in the hundreds, this isn't worth doing.
• We could index certain fields of model runs, but again that won't be necessary if the number of model runs is on the order of hundreds.
• We could switch to cursor-based pagination, but that would have negligible impact until there are far more model runs in the database.

The thing remaining to do on this issue is to add the calls to the stats computation method in any of the places we need to.

[zachmullen]

If there's an easier way of getting AsGeoJSON's result into a deserialized python object, I'd love to know it.

[zachmullen]

This is ready for review. It contains a breaking change for model runs that are created through the REST API rather than processed via the ModelRunUpload pathway. Namely, once all data underneath a model run has been added, it is the clients' responsibility to POST to the new /api/model-runs/{id}/finalization/ endpoint, which will ensure all the relevant stats are computed and saved on the model run.

[mvandenburgh]

This is ready for review. It contains a breaking change for model runs that are created through the REST API rather than processed via the ModelRunUpload pathway. Namely, once all data underneath a model run has been added, it is the clients' responsibility to POST to the new /api/model-runs/{id}/finalization/ endpoint, which will ensure all the relevant stats are computed and saved on the model run.

Sorry, I missed this message @zachmullen. I'll take a look at this