refactor: Start DRY'ing filtered paginate code

[ValarDragon]

Description

Reduce some of the lines of code in this filtered paginate code. Got linked to it, and got bothered by how much code repetition / extra logic there is.

Feel free to close if not worth the review capacity, or to take over.

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests - Covered by existing. (See erroneous changes failing earlier!)
• added a changelog entry to CHANGELOG.md - Not at all user facing
• included comments for documenting Go code - Strictly makes the code easier to understand imo
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[ValarDragon]

Ah I got this wrong right here, because it looks at iterator.Key(). (Which is a different value in this loop)

This is a bit annoying to make consistent with the old behavior. Will adjust the de-duplicated loop to get this consistent

[ValarDragon]

Basically the old behavior would ideally worked with numHits = end right here.

But it actually made nextKey skip to the next hit, which is kind of annoying to get to work.

[ValarDragon]

The current PR has this problem fixed.

In a later breaking release when redesigning the Filtered paginate, I would recommend changing this behavior. (As it will both be more correct from a performance expectation perspective, and code quality cleanup. We could delete all the extra for loops everywhere.)

However this PR is fully non-breaking.

[ValarDragon]

Failing tests seem like github issues? (They all say rate limit)

All actual go tests still pass

[ValarDragon]

Ready for review / no more planned updates!

[testinginprod]

LGTM, minor nit for docs reason. Thanks.

[ValarDragon]

Putting into the merge when ready queue (as its blocking another PR), and is fully compatible / not state machine affecting