Fix #1083, in InfiniteLoader prefer multiples of minimumBatchSize

[luke-gumbley]

For the first and last unloaded range, instead of accepting any size
over minimumBatchSize, scan forward/backward until reaching a multiple
of minimumBatchSize (if possible). Modify tests to reflect the new
behaviour.

[bvaughn]

Why is this better?

[luke-gumbley]

Issue #1083 has an example. The way it stands, if you can scroll through (minimumBatchSize - threshold) rows faster than the API can load them, InfiniteLoader will then call loadMoreRows for every row you continue to scroll past. This is because scanForUnloadedRanges only specifies a minimum size for the first and last ranges, which defeats the memoization (because the upper bound changes by one row each time).

For a potentially unbounded range (such as the first and last range), specifying the size be a multiple of minimumBatchSize reduces the number of calls in this scenario by a factor of minimumBatchSize.

If there are 5 visible rows, threshold is 10, and minimumBatchSize is 20, before the change you get:
scroll at 0: loadMoreRows(0,19)
scroll to 1-4: <no call>
scroll to 5: loadMoreRows(0,20)
scroll to 6: loadMoreRows(0,21)
scroll to 7: loadMoreRows(0,22)
etc.

After the change, you get:
scroll at 0: loadMoreRows(0,19)
scroll to 1-4: <no call>
scroll to 5: loadMoreRows(0,39)
scroll to 6-24: <no call>

None of this changes the underlying requirement that consumers maintain their own record of which rows have been requested. It's a minor improvement to the memoization in cases where that record is not being kept, and results in no change at all if that record is being kept.

[bvaughn]

Sorry for the very long delay in getting back to you about this!

I've just finished a large update for version 10 of react-virtualized (#1900): the library has been rewritten in TypeScript, every component is now a function component (React 18+ is required), and the source moved from source/ to lib/. Because of that, this PR can't be merged as-is. Version 10's InfiniteLoader still uses the same logic for extending unloaded ranges to minimumBatchSize, so #1083 still applies.

If you're still interested in this change, I'd welcome a new PR with it rebased onto the version-10 branch (or onto master once version 10 has been merged).