Design decisions around adding threshold signing

[ameba23]

Some stuff that needs to be clear in order to implement t of n threshold signing

1. DKG protocol sessions

Doing DKG to get ThresholdKeyShares involves an initial DKG with only t participants and then a reshare with all n participants, and finally an auxiliary info generation session with all n participants. See the synedrion test for full details: https://github.com/entropyxyz/synedrion/blob/25373111cbb01e1a25d8a5c5bb8f4652c725b3f1/synedrion/tests/threshold.rs#L205

If we want to keep things similar to how they are now, we could bundle all 3 of these into a single 'DKG' protocol session which runs for all n participants, but for the first bit with only t, the extra participants just wait around until they are needed for the other two sessions. I think this would be simpler than having multiple separate sessions where some some parties would need to close and re-establish a connection.

2. Picking initial t parties for DKG

Then we need a way to decide who should be in the initial t group for the DKG and who not. It does not really matter, as in the end all participants get a ThresholdKeyShare. But since it adds slightly extra work it is probably nice if it is psuedo random so not always the same ones get picked. So my suggestion is to use the 'shared randomness' (which includes block number etc), to pick t from n, similar to what we were doing before with selecting subgroup members for DKG.

3. Picking t parties for signing a message

Then finally we need a way to select signers for a particular message. We discussed this briefly in the dev sync. My suggestion is to continue to use the message hash as we were doing for subgroup member selection. But there are some concerns about this.

4. Picking values for t and n

My understanding was that we would initially build this with a fixed set of validators (eg: 4) and use a fixed threshold (eg: 3).

If we rather want to have a dynamically changing t and n, we need to think about how to track what t is (eg: it could be a fixed proportion of n), and what to do if n becomes an unacceptable size. We would also need to expose the reshare protocol in such a way that it can be used for this, as currently in it is only used like refresh - with the parties always staying the same.

[JesseAbram]

1. I agree
2. I agree
3. I say let us allow anyone at first then move to narrowing them, I still like the sig hash option but open to others
4. I think holding this info in the parameters pallet is the best choice and we should target a %, as for a shrinking n, really unlikely in a blockchain scenerio however yes we can later on come up with some contingencies

[HCastano]

Split out into: #898 and #899.