It has been determined that this test isn't really necessary. busybox
gzip is probably not going to break (and would be discovered elsewhere
too if it does...)
fixes#4
A custom extract test includes reading AND writing the extracted archive
contents to /tmp (which is probably a slow disk), so this uses busybox's
gzip -t ("test file integrity") and seems to take about half the time
(~10s vs ~6s measured loosely on pinephone)
The free space check, checksumming, and moving to the final location
will be outsourced to "boot-deploy", so the verification done here is
just to extract the archive to make sure it is valid.
This adds several steps to the "write" action, by writing it to a temp
location, extracting it, checksumming it, copying to destination,
verifying checksum, and using Rename to atomically replace any existing
file in the destination.
This uses sha256 which, after benchmarking, doesn't seem to be any
faster or slower than sha1. md5 was surprisingly slower (on aarch64),
maybe because there are some CPU accelerated things in sha* ?
