Ralf, can I get your thoughts on this.

If you have 10 matches and set @page_size to 10, the returned json has a
next key in the @links target indicating there is another page of results.

Fetching the next link will return 0 items and the json will not have a next link.

You don't see the bug if @page_size is not a multiple of the total amount of matching
pages.

This is a fencepost error. Maybe we need to limit the number of items filtered from
the database to @page_size+1 (currently @page_size). Add the next link only if the number
of filtered items is @page_size+1. Then return the first @page_size items.
This will fix the issue but....

Maybe we shouldn't be pushing the limit down to the database at all. This results
in a larger filter response and possibly a slower response for non-embedded databases 
(mysql/postgresql). But returning the whole set from the database allows us to fix
issue 2551264 where the total_size value is incorrect.

We can still push offset to the database to reduce some returned data since
we can calculate the number of items in the offset as @page_index-1*@page_size
and just add this to the total size of the set.

I think the HTML web interface gets all the data without any limit or offset so we
wouldn't be any worse than that.

This bug was found by the team building the classhelper web-component:
https://github.com/UMB-CS-682-Team-03/tracker