Use range-based pagination for versions

[Mr0grog]

This is a super rough first cut at the logic for range-based pagination for versions (see #579). It’s ugly, problematic, and absolutely not mergeable as-is, but lets us test things out. Still needs:

• Cleanup and encapsulation. (Maybe pull this stuff out into a concern so it can be used on other models.)
• Migration to add the appropriate indexes ((capture_time, uuid), (created_at, uuid) maybe also (page_uuid, capture_time, uuid), (page_uuid, created_at, uuid)).
• Tests.
• Maybe extend to pages? (Not sure it’s worthwhile, there aren’t critical problems there like there are for versions)

Update 2023-01-25: I’m not going to extend this to other endpoints. While it would be nice, the real priority right now is doing the minimum required for edgi-govdata-archiving/web-monitoring#168

Overall Summary

The slow performance of offset-based pagination (when you get a batch of results with a query like SELECT xyz FROM table OFFSET = n LIMIT = m) is a serious problem on the the versions table (really any large table, but in practice it’s just versions for this app). This solves the problem by using range-based pagination (skipping to the place you want in the result set using a WHERE clause that filters to a range of values from at the same field(s) you are sorting by).

For the versions table, that means doing queries based on a different minimum/maximum (capture_time, uuid) or (created_at, uuid) for each page/batch/chunk of results rather than using SQL's OFFSET clause to get to the chunk we want. This is more-or-less compatible with with any existing client, since the next link still works and the chunk_size parameter also works the same.

On the other hand, this introduces some new restrictions:

• You can only sort by one field, and it must be either capture_time or created_at instead of any field(s) you want. We need an index for the fields we want to sort by, and these two are the ones we chose.

• Clients shouldn’t usually be setting the chunk parameter on their own, and will run into problems if they do, since that field is no longer an integer (now it is either a version UUID or a combined "<timestamp>,<uuid>" string).

• The ?include_total=true parameter is no longer supported for versions. There’s just no performant way to do it without additional caching of that field somewhere (count() in Postgres always requires a full table scan; the entire point of this change is to prevent us from doing large scans in order to paginate results).

There’s also plenty in here that’s not perfectly clean, and not totally generalized. If we wanted to utilize this kind of pagination for other models/controllers, it would need some work to make more abstract.

[Mr0grog]

⚠️ Some important, big deal changes here!

• This changes the default sorting for /api/v0/versions. It is now capture_time:asc. (It was the only thing that sorted in descending order by default; now everything should default ascending.) I couldn’t find anywhere in other codebases where we use this endpoint without explicitly specifying sorting, so it should be ok.
• This changes the default sorting for /api/v0/pages/<uuid>/versions! It is now capture_time:asc (or more importantly, the same as /api/v0/versions) instead of capture_time:desc.
• ?include_total=true is no longer supported for versions. I can’t find anywhere we actually use this for versions (we definitely use it for pages) — probably because of the performance issue — so I think this is OK.