angular holds pull list rows duplicate with multiple pages

Confirmed we are seeing this on 3.9.

Just noting that when this occurs the "Print Full List" option also generates an error, but the list can be retrieved by downloading the csv file or with Print Full Grid.

We have since upgraded to 3.10, and once reaching the last page, however many rows are left display and the first rows do not repeat.

I did some tracing of this:

- The bug occurs in 3.8 and 3.9, but not 3.10 and later - by coincidence
- The pull list grid is intended to fetch all of the holds on the pull list at once, with further grid sorting and navigation being done client-side
- The bug that Lindsay reported and Garry confirmed occurs _only_ in pre-fetch mode
- However, the Angular Circ patches include a change that causes 'enablePrefetch' input to the holds grid component to be ignored entirely in favor of looking for a preFetchSetting. It's not immediately clear to me why that change was made
- Consequently, starting with 3.10, the pull list does _not_ prefetch all holds. This has a couple consequences: (a) the bug does not happen; if you navigate to the last page of results, it won't fetch any beyond that and (b) the displayed holds count is wrong; it just becomes the number of rows returned by the last paged call of open-ils.circ.hold.wide_hash.stream

After some discussion with Bill on IRC, it looks like 'enablePrefetch' getting ignored was an unintended thinko.

So to sum, it looks like what needs to happen is:

- Fixing the handling of navigating to the last page of results when eg-holds-grid is in prefetch mode
- Verifying that that also fixes the issue with 'Print Full List' that Garry found
- Fixing how the holds count is calculated in non-prefetch mode, either by doing a count of relevant holds when the grid is opened or, if the act of counting would be too expensive, adjusting the display of the count to make it clear that the total number is uncertain
- In non-prefetch mode, seeing if we can better detect whether the last page of results is in fact the last (when the total number of holds is an integral multiple of the page size)

This might be one way of doing it: https://gist.github.com/gmcharlt/3b311f7e62a175bb78bf3570c2e05ede

Though perhaps the GridDataSource should instead be setting allRowsRetrieved directly.

Re your final thought, I think the net.request complete callback in fetchHolds, which calls observer.complete() and closes the progress dialog, should probably forcibly set this.gridDataSource.allRowsRetrieved=true if enablePreFetch is true. For API purposes, it seems cleanest to provide a function on GridDataSource that lets the data gathering function set allRowsRetrieved to true rather than poking the flag directly, though TBH that class's shape seems very unlikely to change in a way that we wouldn't want a state flag of the name/purpose.

I'm not sure about the first hunk of the patch -- the data property of GridSourceData objects looks like it starts as (and is reset to, via reset()) an empty array, but that shouldn't have any element of undefined, should it? (I see the check for undefined in getPageOfRows(), but I'm not understanding how (other than bugs) we'd get undefined data elements.)

Updating this to note that while the list displays in full, with no repeats/overwrites regardless of the number of rows selected to display, if the rows to display number is lower than the total number of holds, that number still displays as the count of holds.