Prevent extensions from blocking parallel pre-compilation

[topolarity]

Previously our precompilation code was causing anything with package A as a dependency to wait on all of A's extensions and weakdeps to finish before starting to pre-compile, even if it can't actually load those weakdeps (or the extensions themselves)

This would lead to a pre-compile ordering like:

A        B
 \      / \
  Ext AB   \
     |     /
     C    /
      \  /
       D

Here C cannot pre-compile in parallel with Ext {A,B} and B, because it has to wait for Ext {A,B} to finish pre-compiling. That happens even though C has no way to load either of these.

This change updates the pre-compile ordering to be more parallel, reflecting the true place where Ext {A,B} can be loaded:

  A       B
 / \     / \
C   Ext AB  |
 \    |    /
  \-- D --/

which allows C to compile in parallel with B and Ext{A,B}

Please review 55b40ed (that's the only commit w/ important changes)

[KristofferC]

Bump

[topolarity]

Bump? This is waiting for review

[vtjnash]

Is that counting as a review?

[KristofferC]

yes

[topolarity]

This change is needed for correct-ness, as it turns out.

The existing behavior where we lift to just under the parent tightens the scheduling constraints on triggers too much, leading to false cycles. For example ExtBA and A depends on B starts as:

A -> B

but after injection of ExtBA under its parent B this becomes:

A -> ExtBA -> B
 ^-----/

which has put A and ExtBA into a false cycle. The correct scheduling here is obviously:

ExtBA -> A -> B

Basically the way that ExtBA was added to this graph did not realize that one of the triggers (A) is constrained to compile after the parent already. If we wanted to avoid the cycle, we needed to attach to B instead (or to the LCA, as this PR does)

[IanButterworth]

Makes sense to me from the description.