feat: create complete-deposit sign requests

[djordon]

Description

Closes #563.

Changes

• Remove some of the unnecessary fields from the TxSignerEventLoop and TxCoordinatorEventLoop. We can remove the private key field too but it's better to move that into the wallet so I left it as is for now.
• Removed an unnecessary input from the RotateKeysV1 transaction object.
• Added a method for loading the SignerWallet from the database.
• Added trait functions for fetching "fulfilled" requests from the database, partly implement one of these functions for the postgres type.

There is still some outstanding work here:

• Rename the Fulfilled*Request structs (the requests are only partly fulfilled). Name suggestions are welcome. Done.
• Fix-up the documentation on the Fulfilled*Request structs. Done.
• Add an implementation for the in-memory version of the query. Won't do here.
• Any other name suggestions are welcome. No need, unless they're really really good.

Testing Information

This PR has tests for the function that loads from the database, but is missing:

1. Properly construct a sign deposit request transaction.
2. Properly fetch nearly fulfilled requests from the database. For now, the query that is here is "sufficient", but we can do it properly after [Feature]: Store the requests tied to signer bitcoin transactions #585 lands.

Edit: We have some tests for (2) now, but a full suite of tests require #585 and for us to modify the query included here.

Checklist:

• I have performed a self-review of my code

[matteojug]

nit/question: num_stacks_blocks_per_bitcoin_block: 0 was confusing at the beginning, then I saw that we always include at least one stacks block in test data generate_stacks_blocks. To avoid surprises, should we validate num_stacks_blocks_per_bitcoin_block > 0 or avoid creating a stacks block if the param is zero?

[djordon]

I think it creates zero stacks blocks. I might be missing something, why do you think it creates one block?

[matteojug]

sbtc/signer/src/testing/storage/model.rs

Line 309 in 5073358

let stacks_blocks = (1..num_stacks_blocks).fold(vec![stacks_block], |mut blocks, _| {

It seems to always push at least one block

[djordon]

Ahh, I believe (1..0) is an empty range.

[matteojug]

it seems to be still considering the initial value though:

# dbg!((1..0).fold(vec![1], |a, _| a));
[src/main.rs:5:5] (1..0).fold(vec![1], |a, _| a) = [
    1,
]

[djordon]

Oh, right, well that settles it. My mistake!

Also, I did not take in the confusing part about this test, which is that I use Stacks blocks but ask for zero stacks blocks to be generated. I'll fix this in another PR.

To avoid surprises, should we validate num_stacks_blocks_per_bitcoin_block > 0 or avoid creating a stacks block if the param is zero?

I would think that we should avoid creating Stacks blocks if we ask for zero. For this code, I should probably just update the number of stacks blocks that are needed to avoid confusion. I'll make sure that it is added in.

[AshtonStephens]

Created ticket to track the lack of integration tests here: #631

[matteojug]

Other than the mentioned issues in the PR description (and the two missing nits), LGTM.

About Properly construct a sign deposit request transaction. mentioned in the testing information, what are you referring to?

[djordon]

About Properly construct a sign deposit request transaction. mentioned in the testing information, what are you referring to?

I should change the wording here, I think the full sentence is something like: "test that we properly create a sign-deposit-request-transaction object" or something like that.