bug imports require admin intervention

[Gavin Panella]

Bug imports are currently done by hand:

 * User files a question against malone.

 * If an XML bug dump is not linked to from the question, we must
   request it, and point the user to trac-launchpad-migrator[1] or
   just the XML spec on the wiki.

 * Import into a locally running Launchpad instance.

   The XML produced by trac-launchpad-migrator is good, but often
   requires some fixes, like changing bug nicknames, adding the
   correct namespace. I've not seen XML from anyone else trying to
   implement the spec independently for another bug tracker, but I
   imagine there will be lots of teething pains.

   This often means that there is a lot of toing and froing between
   the requesting user and the Launchpad engineer.

 * Optionally, a demo instance is started on EC2 to show the user the
   results.

 * Import the bugs into staging.

   This can also highlight issues with the import data, so more toing
   and froing.

   It can also conflict with the availability of the LOSAs. If they're
   busy - and they often are very busy - getting the bugs into staging
   can take a day or more.

 * Import the bugs into production.

   Again, this can conflict with LOSA availability.

This is a *HUGE* time sink. We should make this whole process
self-service, so that engineers are only interrupted when something
goes wrong.

Such a service only needs to be available via the API. Upload XML to
the librarian, with a method call via the API from a project owner to
trigger the import. The import can take some time, so should run as a
job, reporting via email.

Also, trac-launchpad-migrator should be extended to do a direct import
into Launchpad via the API when possible.

[1] https://launchpad.net/trac-launchpad-migrator