As seen in BF-38639, running full validation on an active node during initial sync/startup can cause an fassert/EBUSY to be thrown if the oplog applier gets an empty batch and attempts to do lock-free reads on a collection that is concurrently being validated. This situation would rarely be encountered by a user since it would involve running validation on an active node while its in initial sync (which goes against our docs guidance), but it is possible. We changed the test to not run full-validation, but we're filing this ticket as a result of this conversation just to track this scenario and decide if we should actually add concurrency control to the oplog applier to account for this situation.