Mount at /run/virtiofs only what containers bind from there

[MayCXC]

Summary

A container's additional virtiofs mounts are bind-mounted into it from /run/virtiofs/<tag>, so those tags are what belongs there. A virtiofs rootfs is mounted at the container's own rootfs path and nothing binds it, but the per-tag boot walk put its tag under /run/virtiofs anyway, and the hotplug join counted it as satisfying /run/virtiofs for every other container. A container joining with a directory another container boots from was skipped as already mounted, and its bind failed with ENOENT at start.

Deriving the boot walks and the join's already-mounted set from the additional mounts alone makes /run/virtiofs and the set that describes it the same thing. The colliding join then mounts the tag itself, which the guest kernel allows: virtio_fs_get_tree resolves each mount of a tag to the device instance's one superblock (fs/fuse/virtio_fs.c, sget_fc with virtio_fs_test_super), so a tag mounts at any number of places.

Closes#860.

Motivation and Context

The bug needs two containers in one pod and a shared host directory to show up: one booting from it, another mounting it. That is a reasonable thing to arrange, and the failure gives no hint of the cause, since the container that fails is not the one holding the tag.

The underlying confusion is that two different sets were being described by one name. /run/virtiofs is where binds come from; the set of tags that need to be there is the additional mounts. Deriving one from the other keeps them from drifting apart.

Testing

• swift build and make check clean.
• swift test: 603 tests in 83 suites passed.
• Integration suite passes, including the pod tests that exercise hotplug joins.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update