gracefully handle unexpected changes to totalRecords in the middle of paging

When in the course of handling requests, it becomes necessary for Okapi to change the totalRecords value from a SWAG to the actual value, and to assume that among the powers of stripes-connect is the ability to notice that the SWAG was actually a WAG and that it was WRONG, it becomes incumbent upon the authors of that library to declare that this is bonkers, but that, yeah, sure, we can deal that if we have to.

Overview: On the back-end, calculating the exact number of rows in a result set is expensive when there are more than 10,000 rows in inventory, even if there are relatively few rows, e.g. 80, 90, 100, in the result set of a given search. In paged results retrieved with a limit clause, e.g. limit=30&offset=90, this causes the totalRecords value in a result set to vary from 999,999,999 (for pages in a result-set that do not contain the final record), to the exact record-count, e.g. 80, (for pages that do contain the final record).

Steps to Reproduce:

1. Upload more than 10,000 records to folio-snapshot-load
2. Log into folio-snapshot-load as diku_admin
3. Go to Inventory
4. Filter instance records by language, choosing French or German. Scroll to the bottom of the list continuously until the "End of list" marker is displayed.

Expected Results: The instance count should display "More than 10,000 records found" when the results first load and then switch to an exact count when the last page of results loads.

Additional Information: See the long discussion at STSMACOM-259. When the "More than 10,000 records found" work was first completed, the exact count would display, immediately followed by "0 records found". The work here only deals with this bug, i.e. the incorrect display of "0 records found". The inaccurate record count is captured under MODINVSTOR-414.