refactor: replace homegrown Bitcoin RPC for bitcoincore-rpc-async crate

[storopoli]

Description

Replacing our homegrown solution with an off-the-shelf crate,
bitcoincore_rpc_async(https://docs.rs/bitcoincore-rpc-async).

Commits are atomic in a sense that they don't fail on CI and can be read/reviewed in a interdependent basis.

Also tried to improve all the docstrings of the functions that I had to touch.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature/Enhancement (non-breaking change which adds functionality or enhances an existing one)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactor

Checklist

• I have performed a self-review of my code.
• I have commented my code where necessary.
• I have updated the documentation if needed.
• My changes do not introduce new warnings.
• I have added tests that prove my changes are effective or that my feature works.
• New and existing tests pass with my changes.

Related Issues

EXP-189
Closes #81.

TODO

• Figure out how to catch the specific error -27/-25 in btcio/src/writer/broadcast.rs inside the broadcaster_task function.

[codecov]

Codecov Report

Attention: Patch coverage is 5.09259% with 205 lines in your changes missing coverage. Please review.

Project coverage is 55.36%. Comparing base (1485d2e) to head (d3c653a).

Files	Patch %	Lines
sequencer/src/main.rs	0.00%	90 Missing ⚠️
crates/btcio/src/rpc/client.rs	0.00%	35 Missing ⚠️
crates/btcio/src/writer/test_utils.rs	5.55%	34 Missing ⚠️
crates/btcio/src/reader/query.rs	0.00%	19 Missing ⚠️
crates/btcio/src/writer/broadcast.rs	0.00%	10 Missing ⚠️
crates/btcio/src/writer/writer_handler.rs	0.00%	9 Missing ⚠️
crates/btcio/src/writer/config.rs	0.00%	2 Missing ⚠️
crates/btcio/src/writer/watcher.rs	0.00%	2 Missing ⚠️
crates/evmexec/src/engine.rs	0.00%	2 Missing ⚠️
crates/btcio/src/writer/builder.rs	75.00%	1 Missing ⚠️
... and 1 more

@@            Coverage Diff             @@
##           master     #239      +/-   ##
==========================================
+ Coverage   54.15%   55.36%   +1.21%     
==========================================
  Files         111      111              
  Lines       11964    11702     -262     
==========================================
  Hits         6479     6479              
+ Misses       5485     5223     -262     

Files	Coverage Δ
crates/btcio/src/writer/utils.rs	86.70% <100.00%> (+0.17%)	⬆️
crates/btcio/src/writer/builder.rs	95.64% <75.00%> (+<0.01%)	⬆️
sequencer/src/l1_reader.rs	0.00% <0.00%> (ø)
crates/btcio/src/writer/config.rs	0.00% <0.00%> (ø)
crates/btcio/src/writer/watcher.rs	0.00% <0.00%> (ø)
crates/evmexec/src/engine.rs	68.94% <0.00%> (ø)
crates/btcio/src/writer/writer_handler.rs	40.22% <0.00%> (-0.46%)	⬇️
crates/btcio/src/writer/broadcast.rs	0.00% <0.00%> (ø)
crates/btcio/src/reader/query.rs	0.00% <0.00%> (ø)
crates/btcio/src/writer/test_utils.rs	31.81% <5.55%> (-22.73%)	⬇️
... and 2 more

[bewakes]

What are you refering to here? The Err(e) block or the cfg(debug_assertions) thing?

[storopoli]

This will be removed once I figure out the

Figure out how to catch the specific error -27/-25 in btcio/src/writer/broadcast.rs inside the broadcaster_task function.

in the TODO list of the PR description.
It will not be in the finished ready to review state.

[bewakes]

Looks good to me.

One thing is that I am not sure if we should split the rpc interfaces to what a reader, signer and publisher might be using. For example, reader does not need to publish/sign transactions, while a signer does not need to publish transactions whereas publisher does not need to sign transactions. All are inside one trait in this PR, but I guess that's fine too. What do you think?

[storopoli]

Yes, I agree that this might be interesting in the future.

I just don't think that the added complexity is worth right now.
Maybe we can add to a ticket later.
I think that unifying everything into a single trait solves the issue right now and keeps the complexity low.

But I might be wrong, there might be something that I am not seeing here...

[storopoli]

Currently the tokio runtime in sequencer/main.rs probably has some sort of crazy infinite recursion and we are getting:

thread 'express-rt' has overflowed its stack
fatal runtime error: stack overflow

I am struggling to debug since I cannot force cargo to output any trace in the functional tests.

[storopoli]

The rebase is too painful and effortful. Closing in favor of #245.