Improve walt image shell to allow advanced commands currently failing

[eduble]

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).

[eduble]

how do we inform walt-init about which way its read-write overlay layer should be mounted?

Actually, since the server is responsible for copying walt-init script when the image is mounted, it could provide an alternate implementation in this case.

[eduble]

About the node:<node-name> backend idea.
The bootup procedure could add and modify files, having these modifications included in the recorded layer is not very clean.
We might be able to setup this specific mount only for the time of the SSH connection?