feat: fall-back to current signer set + threshold from contract for stacks tx validation

[cylewitruk]

Description

Changes the tx-signer's assert_valid_stacks_tx_sign_request() method to use the current signer set public keys & threshold according to the following rule set.

⚠️ This PR builds on-top of (and includes) #1315 and targets main, so changes from both PR's are in the diff.

With only #1315, we would be unable to submit a rotate-keys contract call if any of the signers were missing the dkg shares entry for the current aggregate key. This PR adds a fallback mechanism for this case.

/// 1. First, we attempt to retrieve the information from the database.
/// 2. If the database does not contain the information, or we receive an
///    error from the database, we fall-back to the contract.
/// 3. If we couldn't get the information from the contract, but the
///    contract calls returned valid "not found" responses (i.e. `None`
///    here), then we're likely bootstrapping and fall-back to the
///    bootstrapping configuration.

Changes

• Adds a new StacksInteract method for retrieving the current-signature-threshold from sbtc-registry.
• Updates the current StacksInteract method for retrieving the current-signing-set from sbtc-registry to return an Option<>, and None if the Stacks node returns a 404.
• Updates assert_valid_stacks_tx_sign_request() to use a new method get_current_signer_set_public_keys_and_threshold() for retrieving the signer set public keys and signature threshold, which uses the above rule set.

Testing Information

• Added new tests for the StacksInteract changes.
• All existing tests pass, including the new test from feat/modify rotate key to ask for all signatures #1315.
• Ran through devenv with a deposit and everything looks good.

Checklist:

• I have performed a self-review of my code
• My changes generate no new warnings
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[cylewitruk]

@djordon @matteojug do we want this functionality (without #1315, i.e. just the fallback logic)? If so, I can open a new PR with this not based on #1315, otherwise we can close this.

[djordon]

I think we want something similar to this PR for when we want to onboard a new signer. I would break it up into more targeted PRs though.

1. A PR for the current signing threshold and the change to use an Option as the return type for the data variable.
2. Another PR with the changes to signer/src/transaction_signer.rs but done a little differently. The most substantive change is that we probably want to move that logic into the block observer so that it gets put into the signer state.

I'm not a fan of the changes to the signer/src/transaction_coordinator.rs