This approach is more thorough when completing range requests, but it blocks seek requests when processing large amounts of ranges. Accounting for this seems like it would add more state at the replicator level for tracking where the cursor left off etc.

If we keep _updateNonPrimary's workload small but:

1. make it pick random subset of ranges to avoid stacking unfulfillable ranges at the front.
2. trigger non-primary updates more often, maybe when inflight goes idle

We can allow it to yield to seeks while being a minor change. I have the following competing PR with the above, which still doesn't pass atm. #841

Did another pass. Still need to cover some of the tests but found a potential way that ranges now can be blocked instead of seeks.

Only one test i'm not sure what it's purpose is, but otherwise only notes about seeks vs ranges behavior for the PR in the future.