cmd/snap-update-ns: handle anomalies better

[zyga]

When snap-update-ns decides to mount or unmount something, it makes the
decision based on the differences between mount profiles - fstab like
files that describe what is probably mounted and what should be mounted.
Actual mount table is much more complex, containing mounts performed by
snap-confine as well as the effect of complex recursive bind mounts and
unmounts.

As an analogy, we navigate a submarine not by looking out the window but
by looking at a map and our internal instruments. We may run into
problems if there's disagreement between the outside world and our
simplified representation.

This patch provides two improvements to situations when our internal
representation disagrees with reality: one for umount failing with
EINVAL and anther for rmdir/unlink which fails with ENOENT. In both
cases the idea is the same, we try to remove something which is not
there.

In the first case, when unmount fails with EINVAL, we can check if the
path we intended to unmount is really a mount point. If it is not then
the call has failed because our desired result is already present.

In the second case, when removing a file or directory fails with ENOENT
then the object is clearly already removed.

In both cases we can continue instead of failing.

Ref: https://bugs.launchpad.net/snapd/+bug/1884849
Ref: https://forum.snapcraft.io/t/18393/10
Signed-off-by: Zygmunt Krynicki me@zygoon.pl

[cmatsuoka]

Thanks Zyga. Assuming that the PR text correctly describes the problem, the fix implementation looks sane and should address the issue.

[cmatsuoka]

By the way, thanks for the detailed PR message, it makes it much easier to understand the issue and match the actual implementation with what was intended by the author even if the reviewer is not completely familiar with the subsystem being worked on.

[bboozzoo]

Little tweaks and a question about the spread test

[bboozzoo]

Thanks