Hardening visibility-map maintenance and recovery

Hi,

After getting involved in the discussion of corruption caused by
CREATE DATABASE (from template) STRATEGY WAL_LOG [1], I started
thinking about how we could prevent and fix VM corruption in more
cases.

After ed62d26caca, the idea was that both setting and clearing the VM
always registered the VM block, so we would be protected against VM
corruption. This turned out to not work if the VM got removed somehow
from the primary or standby and they got out-of-sync (like in [1]). I
have some stop-gap fixes proposed for that in [2]. However, I think if
we make some bigger changes, we can prevent and repair scenarios like
this.

The patches attached do the following visibility map hardening:
- WAL-log page corruption repair so that it is propagated to the
standby (and isn't lost after a crash). Also extend page corruption
repair to cover a few more scenarios.
- Register the VM buffer whenever INSERT/UPDATE/DELETE clears
PD_ALL_VISIBLE, even if the VM bits were already clear on the primary.
This repairs divergence and can't result in torn pages during recovery
like the stop-gap strategy.
- Stop reading the VM with RBM_ZERO_ON_ERROR. Introduce a new mode,
RBM_ZERO_ON_MISSING, that allows extending if the page is not created
yet but errors on corrupt pages.

This series also makes zero_damaged_pages a string instead of a
boolean so you can specify 'vm' instead of just on and allow you to
ignore and zero out the VM if it is corrupt during recovery.

There's also a patch to stop masking PD_ALL_VISIBLE WAL consistency
checking during recovery in [3] (see v6-0002), which I plan to commit
soon once sources of this kind of corruption are fixed.

The aim is to prevent avoidable divergence, make repairs durable, and
leave better evidence when corruption does occur. (note that patch set
doesn't have tests yet)

- Melanie

[1] https://www.postgresql.org/message-id/CAAKRu_bK7oJvtrrzL_V-OHouCWDKyU2-ERv%2BQvV6XM9Wh2dpUg%40mail.gmail.com
[2] https://www.postgresql.org/message-id/CAAKRu_bApoksLDb-HX0GYciU3uLWqA1JagntaV8GP0%3D%2BidehHw%40mail.gmail.com
[3] https://www.postgresql.org/message-id/CAAKRu_aRdQ6RjneKeQh9%2BRVMFgMrtjTYFX%3DzDgBdSiQ8JDs6Jg%40mail.gmail.com