Receive a snapshot from a host that has it

[ccomb]

Buttervolume could send a snapshot to another host and never fetch one back, so
a container moved to a second machine started on the empty volume of that
machine while its data sat next door. buttervolume receive <host> <volume> is
the other direction. It is the piece a synchronization at mount time needs,
extracted from #69 on its own, and it does not touch mount or unmount.

It names a volume where send names a snapshot, because whoever receives does
not know what the other host has, which is the question being asked. The most
recent snapshot that host keeps is fetched, incrementally when the two sides
still share an older one to build on, and its name is printed. It restores
nothing: which snapshot becomes the volume is a separate decision, and this
command is not entitled to make it.

A host that could not answer is never read as a host with nothing. The
version of this in #69 reads the standard output of ssh and never looks at its
return code, so a host that is down answers an empty listing, which reads as a
host that keeps no snapshot. Acting on that is how the good copy of a volume
gets replaced by an older one while the machine holding it was simply
unreachable. Here the listing raises when ssh fails and when it takes too long,
and an empty answer only ever means a host that answered and keeps nothing.
The whole directory is listed rather than a volume@* pattern, because ls
leaves with the same non-zero status when nothing matches as when it failed,
and because the pattern would carry a name into a shell on the other machine.

A trace is not a snapshot. Choosing what to fetch is a computation on two
lists of names, so it lives with the naming rules and is tested without ssh or
BTRFS. Only the snapshots count: a host keeps its own www@date@node3 next to
them, that name sorts after the snapshot it was made from, and fetching it
would write locally the trace of a send nobody made, which the next send to
node3 would then build on.

What a receive leaves half written carries the name of a whole snapshot. So
the answer to "do we have it already" cannot be the presence of that name, the
way the send side can read a trace it only writes after a transfer went
through. A subvolume that is not read-only is what a receive left behind, and
it is named in the error rather than deleted behind the back of whoever might
want to look at it. The one this call created itself is taken away, so a failed
transfer does not block every later one, and a lock is what makes "this one is
mine" true.

The exchange is remembered. The trace <volume>@<datetime>@<host> is
written after a receive as it is after a send, since a snapshot that just
arrived from a host is a snapshot that host holds. Without it, a host that
received a volume would send the whole of it back the first time it changed, to
the host it came from. Writing that trace now has one place instead of two.

Verified: 96 passed, 10 skipped under test_local.sh and 106 passed under
./test.sh. Twelve new tests, among them two that restore what came back
and read the file, one that proves an unreachable host is an error and not an
empty host, one that proves the incremental transfer asks for the parent both
sides hold and never falls back to the whole volume, and one that proves a
received snapshot is not sent straight back.

One thing those tests cannot prove, and the comment in them says so: both hosts
share a filesystem on the test bench, so the parent of an incremental receive
is found there by its received UUID. Between two real machines the local parent
is the original rather than a copy, and btrfs receive falls back to looking it
up by plain UUID. Should that ever fail, the whole volume comes over instead,
which is the same fallback the send side has always had.