randomize and "concurrencize" the flow

[mimoo]

Currently the orchestrator chooses a non-random set of threshold nodes to perform a signature.

See https://github.com/sigma0-xyz/zkbitcoin/blob/main/src/committee/orchestrator.rs#L81

        // pick a threshold of members at random
        // TODO: AT RANDOM!
        let threshold_of_members = self
            .committee_cfg
            .members
            .iter()
            .take(self.committee_cfg.threshold)
            .collect_vec();

right after these lines, we perform two rounds of the signature protocol. These two rounds are sequential (round 2 must come after round 1 is finished), but within a round the request to the MPC nodes can be done concurrently!

Furthermore, I think we should reach everyone at round 1, then ignore (and log) the ones that don't respond, and once we get a threshold go to round 2 only with that threshold (the first threshold nodes that respond basically).

The code:

        // TODO: do this concurrently with async
        // TODO: take a random sample instead of the first `threshold` members
        // TODO: what if we get a timeout or can't meet that threshold? loop? send to more members?
        for (member_id, member) in &threshold_of_members { // <-- we do this sequentially instead of concurrently!!
            // TRUNCATED...       
            let resp = json_rpc_request(
                &rpc_ctx,
                "round_1_signing",
                &[serde_json::value::to_raw_value(&bob_request).unwrap()],
            )
            .await
            .context("rpc request to committee didn't work")?; // <-- we return instead of ignoring!

[mimoo]

some example code #9

[thogiti]

@mimoo Can you please review this?
I added the code for randomizing and adding concurrency to selecting members.
main...thogiti:zkbitcoin:randm-concurrent-orchestrator

[mimoo]

ah nice! if you create a PR I can comment on it :o