Change-Id: I5e3c2881389b0fc3e8a3568850df668efd00315f

The docs no longer matched reality.

Change-Id: I9ee98e16fc03489569bbed8355416a73f7bc02ff
Closes-Bug: 1579890

Change-Id: Id9adbc50bd51adc77ce88f698ad0ea2ee63fc5e2

The library packaged mock seems to work
better across python versions, so instead of
trying to mix the system one and the library
one always prefer the library one (which should
work in all supported python versions).

Change-Id: Id6ada69df9961a6b7511316e2f75ef9ee5f0b72b

Instead of waiting on futures to complete that may still be
in an executors backlog (aka, not even started yet) we can
avoid even executing (and waiting on these to finish) by
forcing them to be cancelled and handling this when analyzing
the futures result (by doing nothing with the cancelled result
of a future).

This saves some time when doing suspension with executors that
have a very small pool of workers that actually run tasks/atoms.

Change-Id: Ie79466c44ac6af5ff8936f192ebce4428aa12d98

Currently when a string is passed to the parallel engine
it will only know how to create a process or a native thread
based executor. The futurist library also supports making
a green thread based executor, so support creating it.

This will save glance some code that they have to create
a executor based on different options (one of those is a
green option).

Change-Id: I15c164a38b4445d28eb6062aed6c56cce0e0364b

Previously stopping the conductor would only prevent it from
accepting new jobs.  This change makes it abort the current job
by telling the engine to stop processing tasks after the current
ones finish.

This allows for conductors to gracefully exit when receiving a kill
signal (although the signal handling is not done automatically yet).

Change-Id: Ie6ddcbb2df4508ad1e3f6698c6f4cb2fc26a278f