ci: add transaction package integration tests

[djordon]

Description

Address part of #67.

This PR mainly sets up integration tests with bitcoin-core. Specifically it:

1. Makes sure bitcoin-core is running in CI in regtest mode.
2. Add helper functions and structs for running integration tests with bitcoin-core in regtest mode.
3. Adds an integration test that makes sure that the signed version of the UnsignedTransactions returned in the utxo module successfully moves deposits to the signer's UTXO.
4. Updates the Schnorr public keys in the utxo module to use XOnlyPublicKey since bitcoin-core expects Schnorr public keys to be 32-bit x-coordinate only keys.
5. Change tests to run on every push instead of only when the PR is open and changes have been made to it. I don't mind changing this back.

Testing information

This PR mainly adds tests but also changes how testing is done. The biggest difference is that cargo test now runs our integration tests and will fail if bitcoin-core is not running locally. To get around that do cargo test --lib or make test if you don't want to run integration tests. Running make integration-test now starts a docker container with bitcoind and stops the container if tests succeed.

Checklist

• Code is commented where needed
• Unit test coverage for new or modified code paths
• make integration-test passes

[djordon]

Is this supposed to be here? It showed up after the rebase, I'm not sure if I need to gitignore it something.

[AshtonStephens]

This is certianly my fault, and this makes me realize I don't think I understand the idioms around lock files. Do these need to be in each package, or is pnpm meant to make package-lock.json files within the workspace root and not each sub package.

[djordon]

Ohhh I see. I thought that it's supposed to be committed to the repo in this directory, but I'm not entirely sure. I'll find out.

[netrome]

I don't know about that particular lock file, but when it comes to committing lock files or not the rule of thumb I'm following is that it should be committed for binaries but not for libraries.

Since this is primarily a binary (or a set of binaries) we're developing and not a generic library to be imported by other people, I believe we should generally commit lock files.

Though this is a Cargo convention, and I don't know what the convention is in JavaScript land.

[djordon]

So I think this was generated from my .generated-sources/emily/build.rs file, which calls npm still. Should I just delete that file, is it still relevant?

[netrome]

For this PR, I would like to see it deleted because it's irrelevant for #67. But I'd be open to seeing it committed as a follow-up depending on what convention we'd like to follow for this file. But it should either be committed or explicitly ignored in .gitignore.

[AshtonStephens]

Yeah, we still need it because it adds the clippy labels to to prevent the clippy warnings.

But we could certainly have it call pnpm, I'll change that.

[netrome]

Wait I'm confused, the lock file doesn't add any Clippy labels right? I mean, I frequently delete it from my local repo and that seems to be alright.

[djordon]

Wait I'm confused, the lock file doesn't add any Clippy labels right? I mean, I frequently delete it from my local repo and that seems to be alright.

I think he was referring to .generated-sources/emily/build.rs. Also, should that file be unignored?

[djordon]

We should figure this all out in a separate PR. I'll be removing this and adding it back later.

[AshtonStephens]

This is certianly my fault, and this makes me realize I don't think I understand the idioms around lock files. Do these need to be in each package, or is pnpm meant to make package-lock.json files within the workspace root and not each sub package.

[netrome]

It's great to see these integration tests! I just have some nits and style opinions.

[netrome]

For this PR, I would like to see it deleted because it's irrelevant for #67. But I'd be open to seeing it committed as a follow-up depending on what convention we'd like to follow for this file. But it should either be committed or explicitly ignored in .gitignore.