Inferring arguments to compound SPs in dependency traces in Mite crashes

[axch]

Consider a program like this, that performs inference on an argument to a compound procedure application:

(eval_in
 (do (assume x (normal 0 1))
     (assume inc (lambda (y) (+ y (normal 0 1))))
     (assume z (inc x))
     (s <- (single_site_subproblem (toplevel 1)))
     (p <- (extract s))
     (regen s (rest p)))
 (graph_trace))

This crashes on trying to extract a node that has already been extracted.

The sequence of events is this:

1. Scaffold construction begins with the application that defines x.
2. Since x is principal, it registers a proposal kernel and asks scaffold construction to propagate to its children.
3. Scaffold construction propagates into the evaluation of the body of inc and registers proposal kernels for y and the addition.
4. Scaffold construction processes the application of inc that defines z due to its request body changing and registers a propagate kernel [*].
5. Separately, scaffold construction processes the same application of inc because its argument changed and registers a proposal kernel (because that's what compound procedures do when asked how to treat updates to their parameters). The proposal kernel takes precedence over the propagation kernel.
6. Extraction invokes the proposal kernel for the application of inc and unevaluates its body.
7. Extraction also tries to extract along the kernels registered in step 3 and crashes.

The pairs of subsequences 3-4 and 5, as well as 6 and 7, may be reordered, but the result is the same.

Fundamentally, this seems to be a consequence of #653, but perhaps there is a solution that will serve for the time being.

[*] Actually, it may register a proposal kernel here too, depending on details of how exactly the code is written, but the crash happens anyway. The collision is not between different kernels at z but between unevaluating z and trying to extract inside its body as well.

[axch]

The branch https://github.com/probcomp/Venturecxx/tree/mite-request-constraint-kernels contains a very brittle and possibly incomplete resolution to the acute problem, in the form of an implementation of the "More custom kernels" proposal described in #653. For all the reasons listed there, this is not sustainable, but may suffice to push the Venture PPEV chapter out the door.