We've had a trickle of users who accidentally activate the same pool on a
VM and host at the same time. Typically the host doesn't do any IO, but
the kernel will still rewrite the superblock on shutdown. This leaves
the superblock pointing to very out of date btree roots and so we get
massive metadata loss.
This patch changes thin_repair, and thin_dump --repair. They now hunt
for the most recent, undamaged and consistent roots of the device and
mapping trees, and use that as the starting point of the repair.
When opening the corrupted metadata we don't need to touch the space
maps. This used to be achieved by pretending we were opening a
metadata snap at block 0 (superblock location). But got changed in
the recent rationalisation of the metadata constructors.
This patch introduces a bool to the metadata OPEN constructor that
says whether the space maps are needed or not.
