Improve forum threadlist API by using a cursor-based pagination
Description
In !1652 (merged) we switched polling forum threads to the REST endpoint that had been prepared for a while.
This endpoint is forum/{forumId}/{forumSubId}?offset={offset}&limit={limit} which exposes paginated database results based on the offset+limit pattern.
Goal
It would be great to have a stable pagination implemented for this, replacing offset+limit, and ideally completing this before other clients such as our apps are relying on a certain return value structure.
Evidence
If a thread is added between fetching the last page and triggering a new fetch, we are duplicating the last item of the previous page (and missing the most recent i.e. newly created thread of course, which is not something we can fix programmatically). The web frontend won't crash -- but it will log an error message and display a duplicate item.
On the other hand, if a thread is deleted in between, it is possible in theory to miss a thread when fetching the next page. Although this probably won't happen too frequently because threads aren't usually deleted, it could still be fixed by the same approach, so it's worth looking at.
Solution
The general solution to these problems is cursor-based pagination, where instead of relying on indices the dataset is queried based on certain unique structural properties that don't change when the dataset itself does (record ID or creation time for example).
As we're supporting sticky threads and threads could also change their stickiness in between fetches, it's not trivial and frontend logic might have to get adapted.