Stop premature burning of presignatures

[ChaoticTempest]

We currently burn a lot of presignatures when we try and make an attempt at a signature. This attempt includes posits, so when we have two nodes that think they are the proposer of this signature, they end up taking their own presignature as an attempt into the signature request.

So instead when proposing signatures, the id for identifying who is proposing should be (SignId, ProposerId) instead of (SignId, PresignatureId).

Note, this requires having the owner keep track of who has what presignature shares via sync, so #371 needs to be done first and with it, consequently utilizing that list of participants to choose which presignature to use

[volovyks]

The PresignatureId is unique and (SignId, PresignatureId) will always be a unique identifier. Unlike (SignId, ProposerId), which can be reused when we iterate over all participants and start over.

Now we are reinserting Presignatures back into storage, so the (SignId, PresignatureId) can be duplicated, but I've removed this in #671.
The issue I see:

• Reinsertion is added because we are losing pre-signatures
• This issue is called Stop premature burning of presignatures, which is possibly caused by reinsertion

@ChaoticTempest can you please elaborate on this? From what I see, we should identify the real reason the pre-signatures are burned. We are recycling presignatures when:

• We are getting a posit deadline during signature generation (my bet is on this, should be related to our current instabilities)
• When we are getting enough REJECT (should rarely happen with State Sync)
• if participants.len() < ctx.threshold (should rarely happen, we are checking for active participants before starting stockpile logic)

cc @jakmeier