snap: Remove libvirt from the snap

[townsend2010]

Maintaining libvirt in the snap causes burdens for not much gain. Anyone wanting to
use libvirt can just use the one installed on the host.

Fixes #482, fixes #846

[Saviq]

I built the snap clean and got this:

The 'multipass' part needs the following libraries that are not included in the snap or base: 
usr/lib/x86_64-linux-gnu/libavahi-client.so.3
usr/lib/x86_64-linux-gnu/libavahi-common.so.3
usr/lib/x86_64-linux-gnu/libicudata.so.55
usr/lib/x86_64-linux-gnu/libicuuc.so.55
usr/lib/x86_64-linux-gnu/libvirt.so.0
usr/lib/x86_64-linux-gnu/libxml2.so.2
These dependencies can be satisfied via more stage-packages, more parts, or content sharing.
…
multipass list
/snap/multipass/x4/bin/multipass: /snap/core/current/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /usr/lib/x86_64-linux-gnu/libxml2.so.2)

Looks like we lost some dependencies.

[codecov]

Codecov Report

Merging #850 into master will increase coverage by 0.03%.
The diff coverage is 70%.

@@            Coverage Diff             @@
##           master     #850      +/-   ##
==========================================
+ Coverage   68.64%   68.67%   +0.03%     
==========================================
  Files         192      192              
  Lines        6608     6606       -2     
==========================================
+ Hits         4536     4537       +1     
+ Misses       2072     2069       -3

Impacted Files	Coverage Δ
...tform/backends/libvirt/libvirt_virtual_machine.cpp	43.44% <ø> (+1.44%)	⬆️
...backends/libvirt/libvirt_virtual_machine_factory.h	0% <ø> (ø)	⬆️
...ckends/libvirt/libvirt_virtual_machine_factory.cpp	42.22% <70%> (-0.64%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7f4e951...1ca55e2. Read the comment docs.

[codecov]

Codecov Report

Merging #850 into master will increase coverage by 0.03%.
The diff coverage is 70%.

@@            Coverage Diff             @@
##           master     #850      +/-   ##
==========================================
+ Coverage   68.64%   68.67%   +0.03%     
==========================================
  Files         192      192              
  Lines        6608     6606       -2     
==========================================
+ Hits         4536     4537       +1     
+ Misses       2072     2069       -3

Impacted Files	Coverage Δ
...tform/backends/libvirt/libvirt_virtual_machine.cpp	43.44% <ø> (+1.44%)	⬆️
...backends/libvirt/libvirt_virtual_machine_factory.h	0% <ø> (ø)	⬆️
...ckends/libvirt/libvirt_virtual_machine_factory.cpp	42.22% <70%> (-0.64%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7f4e951...1ca55e2. Read the comment docs.

[Saviq]

In general this works and the only issue I found is most likely preexisting:

1. snap set multipass driver=LIBVIRT
2. launch an instance
3. stop the instance
4. snap set multipass driver=QEMU

The domain remains defined in libvirt, which may result in weird situations when someone tries to manage it with virsh / virt-manager or some such.

Sorry, fat fingers.

[townsend2010]

@Saviq,

The domain remains defined in libvirt

Yes, this is an already occurring issue. multipassd is ignorant about which backend it used in the previous running instance of the process...which is really the crux of the issue in #854.

[Saviq]

A'ight!

bors r+

[bors]

Build succeeded

• continuous-integration/travis-ci/push