When a standby installs a checkpoint, CheckpointManager::_updateStorageCheckpoint advances WiredTiger's materialization frontier through setLastMaterializedLsn before it hands the checkpoint metadata to WiredTiger. The frontier cannot move backwards, so a pickup that fails after that point leaves the frontier ahead of the checkpoint that is actually installed. The next install with a lower LSN is then rejected with EINVAL.

This forces two awkward behaviours in the step-up path, both added by SERVER-132066:

• A busy pickup at step-up is fatal. The node cannot return to standby once the install has started, because the frontier has already moved, so setCheckpointAndStepUpStorage crashes with fassert 13035202 rather than failing the election.
• Because it cannot wait for long under the RSTL in X, step-up makes three attempts 100ms apart and then gives up. That is unlikely to be long enough for an in-use data handle to be released, so the crash is reachable whenever a pickup is briefly busy during an election.

Moving the frontier advance to after the pickup succeeds would remove the constraint. Step-up could then back out of its retry loop after some number of attempts and return to standby, leaving a later election to retry, and the EINVAL case that fassert 13206604 reports would become unreachable.

Raised by Greg Wlodarek in review of the SERVER-132066 PR: https://github.com/10gen/mongo/pull/59524