In SERVER-82910, we added some logic that truncates the oplog when magic restore starts. This is to discard any oplog entries in the WT journal that came along with the snapshotted data files. We should add an explicit test that makes sure any oplog holes included in the journal files are also discarded. We may be able to modify the existing `magic_restore_non_pit_replica_set.js` test if the changes are minimal, or add a new jstest.

The test should ideally open a backup cursor on a source cluster, use a failpoint to hold open an oplog hole, and then run magic restore. We should ensure that the magic restore logic correctly discards the oplog hole.