Currently, the approach this test uses to make the primary oplog rollover is to just repeatedly insert until we observe the first oplog entry has changed.

This does not lead to a deterministic number of inserts being done, and in certain rare situations it is possible that we do enough inserts to overflow both the primary and secondary oplogs before the primary oplog is truncated, which can cause this test to fail.

We should switch this test to use an approach similar to / the same as oplog_rollover_test.js which performs a specific number of inserts that should overflow the oplog and additionally uses a failpoint to pause the oplog cap maintainer thread as needed to make its behavior more predictable. See the comments in that test for details.