A volume nobody wrote to is not snapshotted again

[ccomb]

This work needed #111, which is now in master. Without it, the second
replication of a volume at rest names a snapshot the remote host already holds,
and the fallback of snapshot_send deletes the good remote copy.

volume_snapshot always created volume@now. A snapshot scheduled every
minute on a volume at rest wrote one identical subvolume per minute, and
replicate:hostA plus replicate:hostB wrote two, which is the case ticket #68
reports.

BTRFS imposes the order. btrfs send needs a readonly subvolume, so a live
volume cannot be compared to a snapshot: the copy is taken first, compared to
the previous snapshot with send --no-data -p piped into receive --dump, and
deleted when the stream carries nothing but its header. It is a deletion, which
rubs against "Destruction stays deliberate" in AGENTS.md, and the answer is that
the thing deleted is the one this very call created and holds nothing that is
not already in the snapshot named back. A comparison that fails keeps the copy.

The comparison lives in btrfs.py and pipes two processes without a shell, with
the four precautions run_btrfs_send_receive documents: the sync first, the
send stderr in a temporary file rather than a pipe nobody drains, the
stdout.close() so the send gets a SIGPIPE, and one deadline for both waits
with the two processes killed and reaped on expiry. The dump is read whole
rather than two lines at a time; --no-data leaves the contents out, and
COMPARE_TIMEOUT bounds the volume where millions of files changed.

Created is part of the subject, not an extra. run_replicate deletes the
snapshot it took when the replication fails. The name it now holds can come from
an earlier round, so without the flag a network outage would delete a snapshot
this round never created: a data loss introduced by this change.
/VolumeDriver.Snapshot answers the flag, api.snapshot returns the pair, the
scheduler reads it, and buttervolume snapshot still prints one name (returning
the pair would break main(), which reads is False as an exit code of 1).

Two existing tests took two snapshots of a volume without writing in between and
counted on both existing. They write a byte now, which leaves what they were
checking intact.

A review of this branch found three things, fixed in the three commits that
follow the first one. The comparison decoded the dump of btrfs receive, which
writes the value of an extended attribute exactly as it is: a volume holding a
binary one raised a UnicodeDecodeError, which is not a BtrfsError, so it
went past the guard that keeps a comparison we could not make from losing a
snapshot. The lines are counted on the bytes now. Two calls on the same volume
at once each compared their copy with the copy of the other, found it
identical, and deleted their own, leaving the volume with neither while both
answers named one: one lock answers that. And the deletion sat inside the same
try as the comparison, so a failed deletion was reported as a comparison
nobody could make.

Verified: 88 passed, 6 skipped under test_local.sh, 94 passed under
./test.sh, including the two new tests that restore the remote copy. And
the scenario the work is for: ten scheduled rounds on a volume at rest give one
local snapshot, one trace, one remote copy, nine "has not changed since" and
nine "nothing to send".