pcli threshold interface is unnecessarily brittle

[hdevalence]

Describe the bug

Using the DKG through pcli involves copy-pasting JSON messages between the participants. We chose this design for two reasons:

1. It's minimally opinionated about the method used to communicate the data between participants (slack/signal/magic-wormhole/etc)
2. It avoids needing to write any intermediate state to disk, which could open up the possibility of replay attacks, where the same secret state is improperly reused between ceremonies.

However, the way this is currently implemented causes a terrible user experience:

• pcli threshold dkg ux: if you hit enter unnecessarily, process is aborted #4260

we are struggling with the pcli dkg flow, we are on attempt 7 now I think.
Hitting enter twice accidentally, accidentally typing and it won't allow backspace, copied with incorrect quotes
With any of those it panics and you have to start the whole ceremony over

We do want to have the behavior of "abort on failure" causing a ceremony restart, without the possibility of improperly reusing any state. But, if we could distinguish between errors caused by copy paste problems and errors caused by a cryptographic adversary, we could substantially improve the UX here.

To do this, we should change the code that reads a single message to retry on any parse failure. This handles issues like #4260 as a side effect, and cannot leak any secrets (because parsing the message does not involve secret data).

[cratelyn]

cross-referencing #4343, which makes some improvements re: hitting enter twice.

[hdevalence]

A common pattern in the threshold code seems to be code like

            for _ in 1..self.config.threshold() {
                let reply_str = self
                    .terminal
                    .next_response()
                    .await?
                    .ok_or(anyhow!("expected round1 reply"))?;
                let reply = from_json::<sign::FollowerRound1>(&reply_str)?;
                acc.push(reply);
            }

This would be cumbersome to add retry logic to in every place. I'm wondering if instead we could change next_response to take a generic type parameter, and bundle the from_json into it internally, so that it waits to successfully decode a message of the expected type and only then yields back to the caller.

[cronokirby]

Closed by #4352