Once rollbackViaRefetch is removed, which should be possible on enableMajorityReadConcern:false is removed, we should no longer have a need for the minValid optime. If we crash during secondary oplog application, we will always recover to a stable timestamp which was set at a timestamp where a complete batch had already finished, so we don't require it for crash resilience in this case. Similarly, recover to a timestamp always recovers to a consistent state post rollback, so we never go through a phase of inconsistency while waiting to reach a minValid timestamp.