[RFC] many: export tools from core/snapd to mount namespaces

[zyga]

This branch contains a quick and dirty implementation of the approach "C" of
https://forum.snapcraft.io/t/12139 - which allows us to update snapd or core
snap freely and keeping updated tools visible to running snaps.

I did not add any tests, but if you run spread you can confirm that this is
indeed working as expected. The code in the new export manager is extremely
simplistic, and in a proper implementation would need to handle many more
cases.

The branch has some logical progression through subsequent patches but you can
see it as the following conceptual list:

• A snap can export content to the host, in a special location that nothing
  currently looks at. This way classic world needs to be adapted to look for
  the new content, with full consequences. I picked the location
  /var/lib/snapd/export/ as the root of exported files. Files can be exported,
  in this implementation, only as symlinks, although other options are possible
  for discussion.

• Similar to implicit slots, both the core snap and the snapd snap gain
  implicit export man that exposes their /usr/lib/snapd directory, as
  core/tools and snapd/tools respectively. Note that the exported directory is
  named after a snap (core and snapd) but in general that is not required. For
  example, many snaps could export fonts to fonts/FONT_NAME or manual pages to
  man/manN/PAGE.N.

• The new export manager handles the new pair of tasks, export-content and
  unexport-content, which are sequenced immediately after link-snap and before
  unlink-snap. Conceptually the export manager should handle the state of what
  is exported from which snaps and how conflicts are resolved. In this naive
  implementation there are no conflicts so everything is just exported at all
  times.

• Lastly snap-confine is modified to bind mount a read-only view of
  /var/lib/snapd/exports/{snapd,core}/tools/ as /usr/lib/snapd/ so that snaps
  using core18 or core20 as base can get a copy of things like snap-exec and
  snapctl. The whole benefit comes from the fact that the tools directory doesn't
  need to be changed via the mount system anymore and that the export manager will
  rewrite the symlinks placed inside. So for example tools/snap-exec will point to
  /snap/snapd/$SNAP_REVISION/usr/lib/snapd/snap-exec - with the full path being
  visible inside the mount namespace.

[zyga]

I'm doing a second pass on this idea with a slightly different details. My plan is to do the following:

The tools from all sources are going to be exported to distinct sub-directories of /var/lib/snapd/export. This design puts all the tools on a plate (from each revision of snaps and from the host) and allows us to atomically switch between them through filesystem manipulation. I will write the details later but the idea allows us to perform atomic and robust "update" that ensures that at no point tools are unavailable.

I'm working on a spike-from-a-spike to get a proof of concept working.

[zyga]

This branch is superseded by a new approach I'm implementing and proposing parts of separately. I will still use some of the code that is present here but as far as the RFC was concerned, it has done its job.