Handle hooks in image.spec

[eduble]

We should handle hooks to be run each time an image is built or modified (by walt image shell, walt image cp, walt image build), or perhaps each time it is mounted.

Here is a sample case where this is important.

Image rpi64-debian is the default image for rpi-3-b-plus, rpi-4-b, rpi-5-b boards. At the time of this writing, it is the only image supporting rpi-5-b boards. Since rpi-5-b boards are supposed to support VPN booting, this image has to support it.

VPN booting relies on a FAT filesystem image at [image-root]:/boot/rpi-5-b/boot.img. This image is only useful when the node boots through the VPN (HTTP booting mode of the firmware). Otherwise (e.g. VPN not enabled on server side), the boards firmware fetches other files of [image-root]:/boot/rpi-5-b/, such as config.txt, cmdline.txt, kernel, initrd, etc. Note that some if not all of them are symlinks. The FAT image boot.img just embeds the same files.

The image provides a script at [image-root]:/boot/update-boot-files.sh which compares the timestamps of the files, so that if one of the files was updated, boot.img is rebuilt. This script is automatically called when the kernel or the initramfs is updated, thanks to standard debian hooks. But if the user modifies config.txt in a walt image shell session or in a Dockerfile, he may not be aware that update-boot-files.sh should be called. This would make the board boot differently when it is booting over the VPN or not.

Similarly, the image rpi32-debian also has a file update-boot-files.sh to regenerate u-boot boot files.

We could imagine to handle a new option called hooks in [image-root]:/etc/walt/image.spec such as:

{
    "templates": [...],
    "features": [...],
    "hooks": {
          "verify": /boot/verify-boot-files.sh
    }
}

At the end of walt image build, walt image shell, or walt image cp, the server would call this script in a container rooted at the root of the new image and print a warning in relevant cases. (e.g. "Verify hook FAILED: You must call /boot/update-boot-files.sh after you update files in /boot!").

We could instead imagine a hook called post-update that would call /boot/update-boot-files.sh itself directly, but this would not be easily implemented in the case of walt image build (should we add a final RUN step to all builds?). Or a mount hook, but this would add processing (often with CPU emulation) probably more often than just letting the user know that the modification he did has a problem.

[eduble]

The hook should also be called after walt node save.

[eduble]

walt image build is a special case because we don't want to add a RUN step visible to the user, so we have to run the hook after the image is built and cannot auto-fix the image.
But for the other commands, it is probably not a problem to run it at the end of the operation, and we could allow auto-fixing the problem.
So when the server runs the hook, it could define an environment variable called HOOK_VERIFY_ALLOW_AUTO_FIX=1 in all cases except for walt image build. The hook script could then behave differently when this env variable is defined.