Improve walt image building tools to allow advanced commands currently failing (edited)

Important note (july 2, 2025)

The title of this issue was previously:
Improve walt image shell to allow advanced commands currently failing

Since then, walt image shell now supports advanced environments (i.e., starting the OS init in the container); the node backend idea could still be interesting in some cases though.
A command walt node save allowing to retrieve the modifications made on the node and save them as a new OS image was also implemented.
By combining those ideas, walt image build could also be improved regarding its RUN commands (as described in next comments below).

So the title was updated to reflect these facts.

walt image shell provides a limited environment based on a podman container.

Currently, it fails to run some advanced commands. For instance, if one wants to install docker on a walt image, docker installation itself will succeed but pulling a docker image from the hub will fail: this would require to temporarily run the docker daemon dockerd in this shell, and this will fail (this is a "docker in podman" case).

One option would be to use sysbox instead of the default container runtime runc. This would would allow more things to work in this virtual environment, including dockerd for instance:
https://github.com/nestybox/sysbox/blob/master/docs/quickstart/dind.md#deploy-a-system-container-with-docker-inside

Another option would be to introduce a new option to walt image shell, called --backend, with two kinds of possible values:

• virtual: the default value; in this case walt image shell would act the same as today
• node:<node-name>: in this case, the shell session would be handled by detecting changes made during a regular ssh connection to <node-name>. This would allow any command which works on a real node. For this to work, on server side a temporary NFS export would be prepared for <node-name>, made of the layers of the current version of the image, plus a read-write directory to store modifications. On node side, walt-init behavior would be altered: it would just mount its NFS root read-write and use no local tmpfs overlay. When the user exits the shell, in order to reflect the modifications made, the directory containing the modifications would be applied as a new layer on top of the image.

This second option would require a little more thinking and tests:

• how do we inform walt-init about which way its read-write overlay layer should be mounted?
• when mounting an image, the server already adds a layer of changes (to provide walt-init and related scripts, ssh authorization setup, etc.), so we should take care not including these changes to the final image.
• the NBFS feature sometimes provided by the image should be discarded in order to ensure an NFS mount (since the node needs a read-write root filesystem mount, with no local overlay)
• walt node reboot should be denied during the shell session. But what if the node reboots by itself (reboot command issued by the user, or side-effect of software installation for instance)? Should we abort the shell session? Or automatically reconnect after the node has rebooted maybe?

Final note: these 2 options could be combined (the first one would improve the virtual backend).

Start with the existing walt image shell, walt image build, and walt node save entry points, then compare the proposed virtual and node backends. Review how image layers, walt-init, NFS, and NBFS are handled. Done should mean advanced commands work while only the intended node changes are preserved in the resulting image.