Stack trace when aborting fetching of artifact list

When launching a command which has no justification whatsoever for downloading the remote artifact list, it is highly likely for the user to hit ^C a few times while BuildStream is taking an eternity to do a useless thing.

In this case, a really ugly thing happens.

The first ^C prints "Aborted!", but buildstream does not return control to the calling shell:

$ bst track base/base-system.bst
Loading:   001
Resolving: 001/001
Fetching artifact list from https://gnome7.codethink.co.uk/artifacts
^C
Aborted!

The second ^C does this ugly stack trace:

^CError in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/lib/python3.5/multiprocessing/popen_fork.py", line 29, in poll
    pid, sts = os.waitpid(self.pid, flag)
KeyboardInterrupt

At this point, you might think you are rid of this... but a child process has been orphaned, it's still trying to talk to the artifact server, how stubborn !

$ ps axf

[...]
 7262 pts/2    Sl     0:00 /usr/bin/python3 /home/tristan/.local/bin/bst track base/base-system.bst

You wont notice the above if you're not looking for it... but it will come and surprise you seconds later, possibly while you are doing something else in your shell:

$ Process Process-1:
Traceback (most recent call last):
  File "/usr/lib/python3.5/multiprocessing/process.py", line 249, in _bootstrap
    self.run()
  File "/usr/lib/python3.5/multiprocessing/process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "/codethink/GNOME/buildstream/buildstream/_artifactcache/ostreecache.py", line 286, in child_action
    q.put((True, _ostree.list_remote_refs(self.repo, remote=remote)))
  File "/codethink/GNOME/buildstream/buildstream/_ostree.py", line 354, in list_remote_refs
    _, refs = repo.remote_list_refs(remote)
KeyboardInterrupt