Refactor: update bdk-bitcoind-rpc to use bdk-bitcoind-client

[tvpeter]

Description

This PR replaces bitcoincore-rpc with bdk-bitcoind-client in bdk-bitcoind-rpc library and its tests and examples.

Depends on bdk-bitcoind-client#5

Notes to the reviewers

• changed the Emitter to a concrete type
• In the example crate, I replaced the shared client between threads with two different clients (will come back to improve this later)

Changelog notice

• replace bitcoincore-rpc with bdk-bitcoind-client

Checklists

All Submissions:

• I followed the contribution guidelines

[ValuedMammal]

Concept ACK

[oleonardolima]

cACK 44bfbf9

[ValuedMammal]

I think the equivalent of GetBlockResult is GetBlockVerboseOne, but this seems to work as well.

[ValuedMammal]

I get this error when running the filter_iter example, don't know if it's something about my OS. I noticed during the transition from bitcoincore_rpc to bdk_bitcoind_client using bitreq. FWIW I don't have the same problem with SimpleHttpTransport because it can create a fresh tcp socket on the fly.

Matched block 205061
Matched block 208441
Error: JSON-RPC error: transport error: bitreq: Can't assign requested address (os error 49)

[tvpeter]

I have noticed this randomly when running tests. Sometimes it passes, other times it fails.

[evanlinjin]

Thanks for this PR.

Before I give it a review, can I please get a bit more context to this Discord message?

In this message, it claims that bdk_bitcoind_client is only meant to support the features we need for BDK. Where else are we talking to bitcoind other than via bdk_bitcoind_rpc?

Sounds like it should NOT be a public crate at all.

Additionally, if the goal is to "support features that we need for BDK", one feature that is missing is the ability to support async IO. The jsonrpc crate that is used internally for bdk_bitcoind_rpc does not support this at all. To elegantly support blocking and async we need some sort of sans-io architecture. I've approached this in electrum_streaming_client, however, I'm not sure if that is the best way about it - would appreciate a look and some opinions.

cc. @notmandatory

[notmandatory]

As a little recap from our discussion yesterday (please correct me if I've missed something), there are two ways to go with this crate:

1. move it into a private module in the bdk_bitcoind_rpc crate since it's not intended for use outside of with bdk.
2. keep it as it's own crate for use as a dependency of bdk_bitcoind_rpc but remove bdk from the name to be more inline with other client crates in the bitcoindevkit org. So something like bitcoind-rpc-client or bitcoind-client but then need to make sure that name is available on crates.io and need to keep it clear in the README it's only going to implement RPC functions and other features needed to support bdk.

The advantage I see of option 1 is it avoids any confusion about the purpose of the client and simplifies release/publishing.

Option 2 could be useful if other related projects like LDK want to use the same bitcoind rpc client for L1 and L2 but they'd need to be OK with exactly the same features bdk needs.