[PATCH 00/26] runqueue changes

[Richard Purdie <richard.purdie@linuxfoundation.org>]

This patchset reworks runqueue so that instead of having two distinct
phases, specifically "setscene", followed by "normal tasks" we have one
single phase.

In this single phase, both sets of tasks can run in parallel using the
same workers. Thankfully the code already used common classes and
functions so making this transition was relatively straight forward.

Initially all tasks are in the scenequeue, as it works through them,
they are marked as "buildable" which means normal tasks can execute.

The big change here are in the code which incrementally marks tasks as
available rather than being able to process tasks "en mass".

The most common failures from these changes are potentially:

a) tasks not migrating from the scenequeue
b) tasks not becomming buildable

I've made some tests on the autobuilder and believe I've tested many of
the common usecases. There is debug code to abort the builds with the
above errors when something unexpected happens.

I've also written an initial set of runqueue unittests. To do that I
had to create a dummy set of metadata so we had some dependency trees
to test with.

This patchset did remove an API we no longer need/use after RSS was
introduced and gets rid of what seems like a pointless form of event.

These changes set up the foundations so that we can work on two other
significant problems:

a) reuse of sstate artefacts between multiconfig build tasks
b) adapting the task queue 'on the fly' if the output of a task matches
   a previous output and hence we have sstate hash equivalency

Solving these would be great for OE!

I will follow up with more details on the future plans for the above
and this code soon.

Cheers,

Richard