From WT-8003, we have noticed that the reshard collection test skews the random cursor due to having a few number of entries per page. The test creates large value sizes for each record where only 10-20 entries can fit per page. The specific test shows a weakness in WiredTiger

1. Calls __wt_random_descent, which randomly from the root page chooses a random child page until we reach a leaf page.
2. If disk records are > 1000, find a visible record from page disk.
3. Look to find a visible record from the insert list
4. If disk records are < 200 or the leaf page is clean, try to find a visible page disk.
5. Last step, clear the cursor position and compute a random record between 0 - 250 entries and perform bt_curnext and bt_curprev until we find a visible record, which can be on a different page than our original page that we descended from.

This ticket aims to look into investigating any changes to the random algorithm specific to the reshard collection test. There has been some recommendations to look into investigating the reasons why we chose magic constants of 1000, 200 and 250 and look into changing up the numbers that work better for this workload. We will also need to be aware that the random cursor doesn't affect the randomness of other test cases too, this can be done through a patch build.