support reinstalling content snaps with --reinstall snap too

[anonymouse64]

We should support detecting content interface connections from snaps and reinstall those as well, since those can slow down snaps as well due to decompression by the kernel. The logic would look basically like:

if slot.Snap != "system" {
    snapshotSnap(slot.Snap)
    removeSnap(slot.Snap)
    snapsToInstall = append(snapsToInstall,slot.Snap)
}

[anonymouse64]

There are a few warts here however,

1. Any other snaps that the user of etrace is using on their system when we remove/reinstall the content snap will end up getting confused and could crash, etc. so we would want to warn the user if they have any such applications running, this requires some more work to identify the running snaps that are using a particular gnome library
2. The re-connections of the snaps could take a long time to do this

I did analyze this however to see if switching the content snaps from XZ to LZO would help significantly (even though that speedup would only apply to the very first graphical snap that uses that particular content snap, all further snaps even on their cold cache startup would benefit from the first one "warming up" the cache for the content snap itself. I used this prepare script:

#!/bin/bash -e

snap remove gnome-3-28-1804
snap remove gtk-common-themes

# CHANNEL=stable/lzo
CHANNEL=stable

snap install --channel=$CHANNEL gnome-3-28-1804
snap install --channel=$CHANNEL gtk-common-themes

(this was with the stable/lzo channel of those snaps that Ken published / built for me)

with this command line option to etrace:

$ etrace exec --no-trace --repeat=10 --cold --silent --prepare-script=refresh-gnome-platform-snaps.sh 1password

The results were:

• with xz compressed gnome snaps avg 14.05 seconds (10 runs) with std deviation of 0.40
• with lzo compressed gnome snaps avg 13.60 seconds (10 runs) with std deviation of 0.56