feat: add blockchain traits module with esplora_async impl

[notmandatory]

Description

WIP to make a simpler API for users to do common sync operations.

Notes to the reviewers

Changelog notice

Checklists

All Submissions:

• I've signed all my commits
• I followed the contribution guidelines
• I ran cargo fmt and cargo clippy before committing

New Features:

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

Bugfixes:

• This pull request breaks the existing API
• I've added tests to reproduce the issue which are now passing
• I'm linking the issue being fixed by this PR

[LLFourn]

Concept NACK.

1. This reintroduces the problem of keeping a lock over the Wallet while doing IO. Removing this is the main goal of v1. You can overcome this by taking in a Arc<Mutex<Wallet>>.
2. This introduces lots of dependencies to bdk::Wallet making long term MSRV policy difficult and we'd be back with different MSRVs per feature.
3. These traits are only appropriate for esplora and electrum i.e. spks style syncing. By having them it makes it seem as if we support this kind of syncing as a more first class citizen to others. My personal feeling is that we should push development of CBF as the best way to use the library when that line of development is accomplished.
4. If we really want some helper methods to simplify use make a trait in bdk_chain that Wallet (or Arc<Mutex<Wallet>>) can implement, then you can have DWIM methods in bdk_esplora and bdk_electrum that sync against any type that implements this trait. The trait would let you query (i) current local chain tip checkpoint and (ii) spks, txids etc of interest.

[realeinherjar]

From our discussion in FFI bindings meeting: can this be an enum?

[tnull]

I want to @LLFourn's points that re-introducing separate async/blocking traits might make it hard to switch between syncing methods during runtime. If these are introduced, I'd prefer if we could make sure all relevant traits are implemented for all syncing methods (i.e., also have async bitcoind/electrum implementations, for instance).

[evanlinjin]

Is the purpose of introducing these traits to make it esier to implement FFI bindings?

[notmandatory]

The initial reason I started looking into this, as @evanlinjin mentioned above, is so the mobile bindings and Rust wallet users don't need to rewrite the same sync logic themselves. Instead I thought I could just throw the the scan/sync logic from the wallet_* examples behind some trait impls.

Concept NACK.

1. This reintroduces the problem of keeping a lock over the Wallet while doing IO. Removing this is the main goal of `v1`. You can overcome this by taking in a `Arc<Mutex<Wallet>>`.

Based on below I can see even if I could do what I'm trying to do without a Mutex it isn't the right approach.

2. This introduces lots of dependencies to `bdk::Wallet` making long term MSRV policy difficult and we'd be back with different MSRVs per feature.

Yes this is a problem and I agree we don't want to get back into all the MSRV and feature problems.

3. These traits are only appropriate for esplora and electrum i.e. spks style syncing. By having them it makes it seem as if we support this kind of syncing as a more first class citizen to others. My personal feeling is that we should push development of CBF as the best way to use the library when that line of development is accomplished.

Long term I'd like to see users using CBF too, but most users today need esplora/electrum so I want to make their lives as easy as possible.

4. If we really want some helper methods to simplify use make a trait in `bdk_chain` that `Wallet` (or `Arc<Mutex<Wallet>>`) can implement, then you can have DWIM methods in `bdk_esplora` and `bdk_electrum` that sync against any type that implements this trait. The trait would let you query (i) current local chain tip checkpoint and (ii) spks, txids etc of interest.

I'm going to close this PR, but I like your suggestion for how to add some sort of helper traits in the bdk_chain crate. I'll try noodling around with that in a new PR. Thanks for all the feedback !

[LLFourn]

I'm going to close this PR, but I like your suggestion for how to add some sort of helper traits in the bdk_chain crate. I'll try noodling around with that in a new PR. Thanks for all the feedback !

Awesome. I'd say start with something like this: #1153 (comment) which simplifies it down to three lines. Shouldn't need any traits either. That approach is better than what I was hinting at above.