Feature - Upgrade to the latest version of WSTS

1. Description

The latest version of WSTS includes two protocol breaking changes:

1. A change in the signing protocol.
2. A change in the network wire format of one of the messages sent during DKG.

Both changes are problematic for the sbtc signer codebase, since the signing protocol changes require a consensus majority of signers to update at the same time in order to avoid downtime. We do not control the sBTC signers so we need to engineer a solution that allows signers to update their systems when they so choose.

2. Technical Details

The WSTS signing changes modify what is hashed during the construction of signature shares. This is a breaking change, so all signers need to ensure that they use the same procedure when signing something using WSTS. Two ways that we could do this are:

1. Have the signers use one protocol for signing before a canonical bitcoin block with a known height is observed and another after.
2. Use one protocol for all old shares, and another after any new shares.
3. Update WSTS to allow configuring which version of the signing protocol to use, and making that configurable in the signer.

@djordon was in favor of doing (1), but his proposed solution would have required having enumerations for every WSTS object that sBTC uses. So instead we are implementing (3). We could still have a block height at which we swap the configuration, or just wait until all signers upgrade, then have them update their configs. The current solution is configured via SIGNER_SIGNER__EXPANSION_TYPE.

Handling the change in network wire format is relative straightforward. We handled this in our earlier effort to update the signers to a later version of WSTS (#1789). The current PR brings that code back into sBTC, with the addition of the signer config which controls the protocol change.

2.1 Acceptance Criteria

• The sBTC signers eventually use the latest version of WSTS for signing.
• The sBTC signers can upgrade their signer binaries at a leisurely pace without risk of causing a conflict.

3. Related Issues and Pull Requests (optional)

Our earlier PR upgrading WSTS #1789, the reverting PR #1808, and the proposed solution is in WSTS stacks-sbtc/wsts#201 and sBTC #1824