Implement cancellation on disconnect, & parallelize Helper aggregation computations.

[branlwyd]

This will be very helpful when we have requests which timeout, which is presented to Janus as a client disconnect. Otherwise, we would continue processing the request until it is complete.

Previously, we used a rayon threadpool for aggregation computations, but the computations within the handling of a single aggregation job were still serialized. Now, we use a parallel iterator for handling each report share in turn, allowing the VDAF evaluations to be performed in parallel. The Helper methods are also updated such that the parallel computations respect cancellation. Specifically, the receiver will be dropped on cancellation, causing the producer threads' sender to return a SendError when they attempt to send, which will cause try_for_each_with to stop processing, which will cause the producer thread to terminate.

Also, remove the (unstated!) requirement in aggregation_job_writer than report aggregations be provided in order. This eases parallelization of the aggregation job continuation logic.

[branlwyd]

A couple of things to pay attention to in review:

• This is mostly "free" parallelism outside of whatever rayon's inherent synchronization costs are, but there are a couple of places that aren't free. First, in aggregation job continuation we now serially build up a new vector associating prepare steps to report aggregations; I think this is required since otherwise we'd need to mutate the report aggregation iterator from multiple callbacks in parallel. Second, I added a sort over report aggregations to aggregation_job_writer, to remove the requirement that report aggregations be in order. If we can drop either of these, we'd see some efficiency gains.
• I'm not totally sure traces/spans are being performed properly, please pay close attention here.

[branlwyd]

Part of #3117.

[divergentdave]

I haven't read the changes closely yet, but I have some early feedback based on testing.

As for tracing spans, we will want to create a span, make it a child of the current span, and pass it to the closure currently used in ParallelIterator::map(). (similar to before) There, we should enter the span at the top of the closure. This will ensure our events logged inside the closure have an enclosing span. Note that the span documentation says "it is entirely valid for multiple threads to enter the same span concurrently", so it's okay to share one child span. We can pass it as the initialization argument of map_with(), so it gets cloned once per worker thread.

[branlwyd]

I merged #3131 into this, as it addresses all current comments. I will update Leader aggregation methods in a follow-on PR, to parallelize the computations & respect cancellation.

Stacked on #3119.
Part of #3033.
Part of #3035.

[branlwyd]

(Rebased on latest main.)