Context
The search_near_01 tests prefix search near's performance. How it does this is through analysing the number of entries that have been traversed for a particular prefix search near. The test also attempts to stress the machine, through calling prefix search nears concurrently across multiple threads. Currently both the default and stress config has 10 threads. WT increases WT_STAT_CONN_CURSOR_NEXT_SKIP_LT_100 whenever it traverses an entry. Because WT increases the stat irrelevant of how many search nears are performing, the search near test accounts for this by factoring in the number of expected entries for one search near * the number of threads that are expected to perform search near.

        expected_entries = tc->thread_count * keys_per_prefix * pow(ALPHABET.size(), PREFIX_KEY_LEN - srchkey_len);

Problem:
The problem starts to appear when a thread performs multiple search nears before another thread can finish one search near. This will produces problems when calculating an accurate number of expected entries traversed across all the read threads. WT-8361, increases the expected_entries by three fold to account for this problem and is not ideal of a solution. This ticket aims to investigate better methods we can test prefix search near, and have an accurate number of expected entries for a prefix search near.