Root and volume overlay filesystem

[mfranciszkiewicz]

• VM root fs is now an overlay over the VM image contents and a directory on provider's disk
  Changes to the root filesystem are stored on disk and are no longer limited by tmpfs size (RAM fs).

• VM root fs can be stored in RAM instead (with the current limit of 128 MB)
  Configured via embedded VM image metadata, set via gvmkit while building the image

• /tmp within the root filesystem can be a separate RAM fs (with the current limit of 128 MB)
  Configured via VM image metadata as a 3rd variant of fs persistence.

• volumes are now an overlay over the the volume directory inside the VM image and a directory on provider's fs
  Volume directory contents are no longer "hidden" during execution.

---

This change is 

[mfranciszkiewicz]

I'm closing this PR due to an UX issue.

Files created inside the volume inherit attributes from the guest machine (uid = 0, gid = 0), which require users to sudo remove the written data and renders the automatic cleaner obsolete. On the other hand, running applications with host user's UID within the guest OS would create additional access issues to the mounted image filesystem, which in turn drifts further away from the default Docker container environment. Another workaround is to set fmode and dmode 9p mount options, but the solution should be compatible with the Windows platform (not tested).

Context:

A wide range of filesystems supported by Linux can be the lower filesystem, but not all filesystems that are mountable by Linux have the features needed for OverlayFS to work. The lower filesystem does not need to be writable. The lower filesystem can even be another overlayfs. The upper filesystem will normally be writable and if it is it must support the creation of trusted.* and/or user.* extended attributes, and must provide valid d_type in readdir responses, so NFS is not suitable.

In order to support 9p filesystem as an upper layer, volumes have to be mounted with a security=mapped* option (effectively, files are written with root's UID). The upper layer as a mountpoint is a requirement for inbound and outbound transfers to work.