api/history: introduce pagination if it makes sense

[austin3dickey]

See #871 (comment).

[austin3dickey]

Today GET /api/history/ is actually quite similar to GET /api/benchmark-results, except

• it's filtered to one history fingerprint
• it only returns default-branch results without errors
• it includes z-score analysis for each result (compared to 100 previous commits' worth of results)

The z-score analysis is where pagination gets a little tricky. Each data point needs 100 previous commits' worth of lookback data to calculate its z-score. This means in order to get a page of data, we need to query not only those benchmark results but also some history, as demonstrated in this diagram.

So querying subsequent pages of data will result in redundant queries of raw data and redundant distribution calculations. This seems fairly important to avoid, especially since this endpoint is a little expensive already. It might be better to query all the data at once and do all the calculations.

So then do we always return all the data in one page? Certain history fingerprints in Arrow already have >1000 associated results. As this scales we might start running into transfer limits. So we need to find a good way to balance the goals I stated in #871 (comment).

[austin3dickey]

I may implement this by returning all data in one page for now, and then revisit after #1512 is completed.

I was wrong before; no calculations would be redundant, just the data querying. But the data querying will be a LOT easier if #1512 is done.