When a segment gets sealed and we jump to a new one, we rewrite several pieces of standby related state at once. There were a few bugs on this rewriting which operated together to leave the standby in a stalled state, or crashed on the next batch.

Fixes:

• Retain prev segment's zones for a bit after topology swap. Materialised offset callbacks from the prev segment's log servers can still be in progress when we swap the topology. Without their zones we couldn't resolve them, materialised LSN stalled, and step up couldn't complete. Hold onto the previous zones in _priorSegmentZones long enough to drain.
• Seed _lastWrittenLSN from the seal record. If we step up immediately after a seal the first AppendLog needs the new segment's previousEntryLsn. Reading the LSN out of the seal record's last_committed_lsns fixes this.
• Don't call updateFrontier for previous segment servers. The MaterializedTracker is rebuilt every _standbyLoop iteration with only the current segment's servers, so a late callback from a previous segment server would fassert when trying to update the frontier. Still resolve the zone and notify mat update for those servers but skip the frontier update

These bugs are only reachable once SERVER-126531 stops the standby from crashing earlier in the seal path.