If a lambda set appears in an occurs chain but it is itself already
recursive, then it is should not be eligibil for modification in the
occurs chain.
Closes#4725
Some tests used to require multiple locks and one test acquired lock A but failed to acquire lock B, another test was holding lock B and required lock A. That way you get stuck! I've turned those multiple locks into a bigger shared one, deadlock proof.
The algorithm for solving recursive definitions proceeds in several
steps. There are three main phases: introduction of what's known,
solving what's not known, and then checking our work of what was
inferred against what the programmer claimed. Concretely:
1. All explicitly-annotated signatures in the mutually recursive set are
introduced and let-generalized.
2. Then, inference type variables (`_`) and unannotated def signatures are
introduced to the cycle, without generalization. The bodies of these
defs, that are either unannotated or have inference variables, are
solved.
3. The defs from step (2) are now let-generalized, since we now know
that their types are consistent. At this point, all the defs in the
cycle have their types introduced and let-generalized, but we still
haven't checked the bodies of the defs froom step (1).
4. Check the bodies of explicitly-annotated defs in recursive set. This
might materially affect the actual types in the signature, for
example do to fixpoint-fixing or alias expansion.
5. As a result of (4) possibly changing the structure of the annotated
type, and because the previous annotated types in (1) were introduced
at a lower rank, we now re-introduce and re-generalize the solved def
types, in the same we did in step (3).
5. The rest of the program is solved.
Now, a very important thing here is that the annotation signature
introduced for (1) consists of different type variables than the
annotation signature introduced in (5). The reason is that they live at
different ranks. Prior to this patch we were not explicilty doing so;
this commit ensures that we do.
