snap-discard-ns needs to be more graceful

[Zygmunt Krynicki]

[Impact]

snap-confine package provides an executable snap-discard-ns. This executable is not on PATH and is only used internally by snapd. In version 1.0.41 this executable would fail if the namespace that needs to be discarded was not available in any way (there was nothing to do but this was reported as an error). Because of a change in snapd this must now be handled gracefully so that when there's nothing to do there are no errors reported.

The snap-discard-ns program was altered to be much more graceful and correctly handle: absence of /run/snapd/ns directory, absence of /run/snapd/ns/$SNAP_NAME.mnt file or the fact if that aforementioned file is not a mounted namespace.

For more information about the execution environment, please see this article http://www.zygoon.pl/2016/08/snap-execution-environment.html

[Test Case]

The test case can be found here:

https://github.com/snapcore/snap-confine/blob/master/spread-tests/main/discard-inexisting-ns/task.yaml

The test case is ran automatically for each pull request and for each final release. It can be reproduced manually by executing the shell commands listed in the prepare/execute/restore phases manually.
The commands there assume that snapd and snap-confine are installed.
No other additional setup is necessary.

[Regression Potential]

 * Regression potential is almost non-existent as the code simply exits more gracefully than before and this executable is only used by snapd which was adjusted to handle the new behaviour.

[Other Info]

* This bug is a part of a major SRU that brings snap-confine in Ubuntu 16.04 in line with the current upstream release 1.0.42.

* snap-confine is technically an integral part of snapd which has an SRU exception and is allowed to introduce new features and take advantage of accelerated procedure. For more information see https://wiki.ubuntu.com/SnapdUpdates

== # Pre-SRU bug description follows # ==

snap-confine 1.0.41's version of snap-discard-ns would fail if the namespace to be discarded was not fully initialised (which is a possible and expected scenario). This has now been fixed so that snap-discard-ns can handle all such scenarios gracefully.

This change is coupled with a change in snapd that makes it handle the error reported by snap-discard-ns.

[Leo Arias (elopio)]

I ran the test in an up-to-date xenial classic kvm, after enabling proposed and upgrading to snap-confine to 0.43.

I got no errors, looks good.