Cursor based pagination currently is "wrong"

**Description**
Ok first things first please don't yell at me for this but:

I think the way Api Platfrom implements cursor based pagination is "wrong" in a way.
Cursor based pagination in Api Platfrom is archived by ordering the query and then using `OFFSET` and `LIMIT` to step through, which is fine for small collections but will be problematic for bigger ones since databases will go and fetch all the rows BEFORE the offset as well.

So in conclusion if you have 10 million entries but want 10million and 20 then you'll fetch 10000020 entries and ditch 10000000 just to get the 20.

Now typical cursor based pagination (as I know it) solves that by using `WHERE` in combination with `LIMIT` to get the results using something like this:
```
... WHERE id > LIMIT X
```
which completely solves that fetching and discarding unnessecary results thing.

The only problem here is that it makes pagination more complex in a sense as you need to serialise the `nextCursor` and the `previousCursor` into your response and use that for your next query to step through.

**Example**
Here is a medium article that explains it rather well:
https://medium.com/swlh/why-you-shouldnt-use-offset-and-limit-for-your-pagination-4440e421ba87

Here's a Slack Engineering blog article as well going over the same thing:
https://slack.engineering/evolving-api-pagination-at-slack/

I like how the used base64 encoded `nextCursor` properties, that way you can serialise extra data and the client won't need to change when the server changes the way pagination is handled for some reason.