This is to ensure "UX-friendly" tasks gets run ASAP.
Quickly explained, this makes sure that the top tasks (e.g. Splash) gets
ran as soon as possible.
Given the list:
- Splash
- Graphics
- AAA
- BBB
- CCC
If `Graphics` ends up running, and AAA, BBB and CCC can too, Splash will
have to wait until all those tasks got ran once!
Not ideal for UX, if e.g. BBB takes time to *run* and we can't show the
progress to users!
The added cost of restarting the queue is minimal with tests I ran. It
was not more than a tenth of a second, and could even be rounding
errors.
This ensures graphical progress is shown ASAP when dependencies are
equally likely to run.
Otherwise, when the graphical step was ready, and switchroot about to
run, the shell step could run before the splash. This means that, in
practice, a long running task like e2fsck could have prevented the
splash to show. It doesn't make sense to make the other tasks depend on
a splash task!
There is no intention to implement any other special-cased ordering. If
there is the need to, it might mean that there is a deficiency in the
design.
This is partly to reduce the amount of loops it needs to run, but mainly
to control the order rather than rely on the order they were added in.
The control of order seems weird in a dependency-based system, but it'll
be used mainly for one thing in the next commit...
