admin: don't use state change to update offset

[minrk]

set offset -> request page -> response sets offset is a recipe for races

instead, send request with new offset and only update offset state based on the actual loaded data

made easier by consolidating page update requests into single loadPageData

this also fixes the problem where the pagination info would be updated before the content, so as seen in #4180, it would go:

0. page 1-10
1. click next
2. pagination updated to 11-20, send request for 11-20, 1-10 still displayed
3. request completes, update display to 11-20

by detaching the "request next page" from the state cycle, the looping requests shouldn't happen. I tried to solve this in general by debouncing loadPageData, but had a hard time figuring that out. And offset is really the only state variable that's an input to the request which can also be set to a new value by the response.

closes #4810

[consideRatio]

Optional cleanup suggestion of now unused setOffset in util file - LGTM!

EDIT: Sorry setOffset is still in use - in Groups.jsx - so my review boils down to the question of it it should be, but if that should be changed also is scope bleed of this PR so LGTM as it is!

[consideRatio]

Very thankful for these function descriptions!

[minrk]

You're right, Groups will definitely have the same issue. Updated it to match.

I think having setOffset defined even though we don't currently use it is still sensible. It's specific to how it's used in these two views, where we call setPagination with the result. If, instead, we used setOffset to trigger the request and didn't call setPagination with the response, that would avoid the issue as well.