Merge lp://staging/~vila/ubuntu-ci-services-itself/testy into lp://staging/ubuntu-ci-services-itself

Update the Test Runner component design and provide the initial API.

Main changes from the trunk version:

* 'test_image' request

  s/test_image(image_url, packages, archive_id, progress_trigger)
   /test_image(test_request_id, image_url, package)

  The rationale is that the caller should do multiple requests if it needs
  multiple test results (otherwise the 'done' request will have to aggregate
  the results and the artifacts and the caller will have to sort them out =>
  unneeded complexity).

* handles a single DEP8 package which produce a single test result and a
  list of artifacts (phase0). For following phases, I'd like to embed the
  articats in the test result itself as discussed during the 'subunit'
  hangout. For now, the request will contain them all, leaving the caller
  store them as it sees fit.

  The rationale is that asking this component to know about the data store
  is coupling them for no good reason.

* new requests: 'done' and 'progress'

Questions:

* messages exchanged between components

We talked about REST APIs and about task queues. I more or less assumed that
a request is added to a queue as a task and the response is sent back when
the task is done (from the queue POV). Feedback welcome.

For the 'done' request, the above works ok, but if we want a REST API and no
queue, I need to know *where* to send that request (some url provided as
part of the 'test_package' request parameters ?).

* progress

Emitting progress and providing an ETA or some estimate of the work already
done raise two issues:

- how many messages should be sent or alternatively at which rate ? Emitting
  the same number of messages for a 1 minute job and a several hours one
  doesn't make much sense. It seems to me that one message very minute or
  every 30 seconds should be enough. But at scale, that may still be far too
  much messages. Thoughts ?

- ETA is a pipe dream so let's settle for estimates to start with. This can
  be be based on the number of tests as long as each test is shorter than
  the interval between two messages. If it's not, we risk misreadings
  between a long test and a hanging test.

If we don't get good ideas there, I'd settle with some arbitrary interval
for phase 0 and plan to acquire the number of tests to initialize 'total'.