Consider more ways of controlling pagination
Lifting @padraic-shafer's comment from #645
Something to be mindful of with paging is whether the results could change from call to call.
For a fixed set of results, will they always be returned in the same order? If not, maybe it's simply the client's responsibility to first sort as needed before paginating.
For a writeable catalog, how does an added/deleted item affect the "pages" that get returned? I think I've seen schemes that include an item id in the pagination request. As in, give me the 10 items before uid-xxxx, or the next 20 items after uid-yyyy. Others use a database-like cursor id to track the position in the results stream.
Results are always sorted. If the client does not specify a sorting, every container adapter (MapAdapter, CatalogContainerAdapter, CatalogOfBlueskyRuns) has a default sorting, so that order is stable across calls.
However, we do not currently support
give me the 10 items before uid-xxxx, or the next 20 items after uid-yyyy.
This might be important for a good UX when paging through results when new results are rapidly being added.