Reimplement Orchestrator::run()

This reimplements the Orchestrator::run() function _again_.

Commit 889649ac16367fe671ce61363bb6ce82531e5a6b was the basis for this work,
improving the baseline so we can take a step further in this commit.

The approach before the change from 889649ac16367fe671ce61363bb6ce82531e5a6b had
one flaw. In the following scenario:

        A
       / \
      B   E
     / \   \
    C   D   F

The nodes C, D and F are selected and then run.
After they all succeeded, the next iteration is checked, and yields that B and E can be built.

But if F takes extremely long, B and E both have to wait until it is ready
(because that's how the implementation works), although B can be built as soon
as C and D are ready.

This patch changes the implementation to the following:

1. For each job, there is a task.
2. The task has a channel where it receives results from its dependencides.
   In above example, B would receive the results of the job runs for C and D,
   and E would receive the result from the job run of F.
3. The task also has a sender where it can send its resulting artifacts to a
   parent task.
   The task _also_ sends the results of its childs. This way we propagate the
   built artifacts up to the root node.

All these tasks are started concurrently.
The "root" task sends the result to the orchestrator.

The task itself is responsible for sending the job to the scheduler and
processing the result.
If the job errored, the task sends that to its parent.
If a child errored, the task aborts its own error and propagates that error.

What does not yet work in this commit:
* Artifacts that were built before the error occoured are not reported yet.
* The staging/release stores may contain artifacts that can be re-used.
  They are completely ignored by now.

Signed-off-by: Matthias Beyer <matthias.beyer@atos.net>
Tested-by: Matthias Beyer <matthias.beyer@atos.net>

0 files changed, 0 insertions, 0 deletions