After the VM has successfully started, check that gvproxy is
still running. If it is not, throw an error and refuse to
complete machine start.
[NO NEW TESTS NEEDED] I don't think we can deliberately trigger a
bad gvproxy start without a bad Podman binary. We could try and
kill gvproxy after it starts but before the machine is booted but
that's very prone to races.
Slightly restructure code so that starting shares happens later
and has its own configuration write - so the VM is still recorded
as running if starting shares fails.
Signed-off-by: Matt Heon <mheon@redhat.com>
5cc5b43473