This also provides us with functions to call when the Manager tells us to
stop the currently running task.

Only logged at debug level. Copied code from the Blender Cloud Add-on,
where it has also been proven useful.

The worker now first aborts any task-fetching task, then queues up any
remaining task updates, then flushes that queue to the Manager, before
finally shutting down.

The job status can change via JobManager.set_job_status() or by PUTting
a job document with a changed status.

The compiler is now actually registering, and the 'format' parameter
is optional. This also required the frame_range_merge() function to
return unicode strings (which is a good idea anyway).

Its meaning was similar to 'claimed-by-manager', which was found to be
more descriptive.

For now, only the job status changes; this doesn't yet cause ripple effects
to the statuses of other tasks belonging to the job.

This function sets the status field of a document in MongoDB to some value,
without fetching the entire document, and without going through Eve. This
is faster, and avoids Eve's permission system (permission is already
known through our own logic).

This thus overwrites the activity string of the last-executed command.

Before this comment, logs & activities would be queued, and this queue was
pushed to master when a log or activity was registered and certain criteria
were met. As a result, when no more logs/activities were registered, the
queue would not be flushed. This is now solved by scheduling a push to
master, and cancelling that task if that push happens for any other reason.

For now we parse the output of Blender and return it as a formatted
string for the 'activity' field. At some point we may want
to consider this as a subdocument of the task (instead of a string field).

Of course this only happens if there were any activity updates at all.

Blender uses n..m instead of n-m.

It performs the work in another coroutine, though, and returns the Future.

Also added runner unittests.

This is required when using asyncio subprocesses, to properly clean up
certain things.

On Windows, the default event loop is SelectorEventLoop which does
not support subprocesses. ProactorEventLoop should be used instead.

Source: https://docs.python.org/3.5/library/asyncio-subprocess.html

This allows the worker to queue up task updates when Flamenco Manager
is unreachable.

Note that asyncio is used for task scheduling & execution, but HTTP connections
and subprocess communication is not (yet). As a result, a blocking POST
call will block proc.stdout.read() in AbstractSubprocessCommand, and
vice versa. This can be solved by using either multithreading or asyncio
to perform those operations.