Remove the end-of-recovery checkpoint in all cases.
For many years, we've been issuing a special end-of-recovery WAL
record rather than performing an end-of-recovery checkpoint when a
standby is promoted. This has the advantage of speeding up promotion.
However, it's advantageous to do this at the end of crash recovery as
well, and for the same reasons. Plus, it's actually simpler this way,
because having only one way to do something rather than two means we
need less code.
We now always request a checkpoint at the end of recovery. If we
crash again before that checkpoint completes, recovery will begin
from the previous checkpoint that we performed - or replayed. This
behavior is not new as far as archive recovery is concerned, but now
it can also happen for crash recovery.
At initdb time, we now initialize the nextXid counter to 4 rather
than to 3. The code for logging standby shapshots and handling them
on th standby can't handle 3, because we set latestCompleteXid =
nextXid - 1, and 2 is not a normal XID. This is arguably a preexisting
bug, but because we didn't log a standby snapshot when starting from
an end-of-recovery checkpoint, we happened not to ever hit the
problematic case.