Add test for Esplora client on Regtest

[thunderbiscuit]

This PR brings in the regtest-toolbox library as a test dependency (not shipped with the release artifacts) in order to control a local regtest node and allow for testing clients in our CI workflows. It also brings in the Regtest Infinity Pro as a service that gets fired up before the CI runs the tests.

We are currently using this setup in bdk-jvm with success.

Using this would allow us to test clients, and better see/verify changes in the API on client PRs (for example in #965).

Notes to the reviewers

Opened as a discussion piece.

Documentation

It does not affect the public API.

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing
• I've added a changelog in the next release tracking issue (see example)
• I've linked the relevant upstream docs or specs above

New Features:

• I've added tests for the new feature
• I've added docs for the new feature

[ItoroD]

ACK 9ad254e

Loving the toolbox

[reez]

has 8 seconds proven to always be enough time for this?

[ItoroD]

So far yes. Check this out too.

[thunderbiscuit]

Yes the 8 second delay is really not a clean way to do this (what if the CI is much slower than local, or the opposite? One side or another you're waiting for longer than you should and it's just overall hacky).

We used this approach to get something working and opened an issue on regtest-toolbox thinking maybe a solution could be added there, but I think @ItoroD's idea of polling the Electrum server until it sees the transaction or block is probably the best way to do this test-side.

I'll add the polling loop here and test locally between runs to see the general feel for it (maybe looping on 1/10th of a second is too much? Maybe not). But in any case I'll use that approach here, and we should clean up the JVM tests as well.

[reez]

yeah the polling loop sounds cleaner, I like it

[thunderbiscuit]

I ended up with this:

// Wait for the Esplora client to see the transaction. Try 5x per second for 20 seconds.
repeat(100) {
    if (esploraClient.getTx(txid) != null) return@repeat
    delay(200.milliseconds)
}

Which usually takes between 10 and 30 loops to complete on my machine.

[ItoroD]

LGTM!

Since this is a closed test setup it is reasonable to call 5 times per second without it being considered spamming.

[reez]

This is definitely a good direction, but I dont think return@repeat breaks the loop? I think it might only return from the current iteration. Maybe we switch this to a while loop or helper that exits early and fails explicitly on timeout?

[ItoroD]

return@runBlocking breaks out of the loop.

[reez]

return@runBlocking is nice but I think it would exit the whole test body here not just the polling loop?

[ItoroD]

Ahh that's what I used in my fork test I think the reason I didn't notice was the test still said success although I have unknowingly existed the program. Blinded by success 😁. Really good catch @reez

This is what I meant to do here return run not runBlocking