We currently have some code to position our cursor at the end of a key/timestamp range in the history store.

The implementation involves search_near running in a loop. So if we do search_near and land on the next key, we call prev to get back to the latest record for our timestamp. If we're still ahead of our key, that means we raced with another insert and we repeat this process. What should really happen is that we call prev in a loop to get to the right spot since this is much cheaper than doing a full-blown search again.

We also have a few spots where we're using our own search_near invocation without this outer loop to guard against races. We should either generalize the cursor positioning function to work for this use case too or we should add a loop to the current invocation to make it correct.