Make `bdk_esplora` more modular

[evanlinjin]

Description

Some users use bdk_esplora to update bdk_chain structures without a LocalChain. This PR introduces "low-level" methods to EsploraExt and EsploraAsyncExt which populates a TxGraph update with associated data.

Additionally, much of the logic has been made to be more efficient (less calls to Esplora) by utilizing the /tx/:txid endpoint (get_tx_info method). This method returns the tx and tx_status in one call. The logic for fetching updates for outpoints has been reworked to support parallelism.

Documentation has also been updated.

This is NOT a breaking change because the API of full_scan and sync have not been changed.

Changelog notice

• Add "low level" methods to EsploraExt and EsploraAsyncExt which populates an update TxGraph.

Checklists

All Submissions:

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

New Features:

• [ ] I've added tests for the new feature
• [x] I've added docs for the new feature

[notmandatory]

Since this is a refactor and won't break the bdk_wallet API I'm not going to assign it a milestone until we get together for a team backlog prioritization call.

[evanlinjin]

Since this is a refactor and won't break the bdk_wallet API I'm not going to assign it a milestone until we get together for a team backlog prioritization call.

That is fine for me. Because some users are waiting on this, I would appreciate it if we have it in soon. It doesn't break any API since it only adds new exposed methods.

[LLFourn]

Concept ACK

[LLFourn]

Hmm I wonder what would happen if we just made updating the chain optional as part of SyncRequest/SyncResult?

[notmandatory]

Concept ACK since it looks like the only changes to the bdk_wallet beta API is renaming start_sync_with_revealed_spks() to build_sync_with_revealed_spks() and start_full_scan() to build_full_scan(). Though in general I'd like to keep API changes in this milestone as close as we can to none.

The return type also changes but it isn't something a user would be interacting with unless they're developing their own SPK based blockchain client (which I haven't heard of anyone doing).

[evanlinjin]

Concept ACK since it looks like the only changes to the bdk_wallet beta API is renaming start_sync_with_revealed_spks() to build_sync_with_revealed_spks() and start_full_scan() to build_full_scan(). Though in general I'd like to keep API changes in this milestone as close as we can to none.

The return type also changes but it isn't something a user would be interacting with unless they're developing their own SPK based blockchain client (which I haven't heard of anyone doing).

Looking at your comment now, I don't think my renaming adds much value, I will change it back.

[LagginTimes]

LGTM so far, will continue reviewing this tomorrow. 👍

[evanlinjin]

@ValuedMammal it should also be possible to calculate fee for all wallet transactions after doing sync

[rustaceanrob]

It is non-intuitive to me to have SyncProgress be a collection of usize fields. It seems as though you can "consume" the SPK and still have the request fail? I might be interpreting this diff wrong but I feel as though the SyncProgress should be derived from a collection of SyncItem rather than being a distinct object

i.e. impl SyncProgress for Vec<SyncItem>

[notmandatory]

It is non-intuitive to me to have SyncProgress be a collection of usize fields. It seems as though you can "consume" the SPK and still have the request fail? I might be interpreting this diff wrong but I feel as though the SyncProgress should be derived from a collection of SyncItem rather than being a distinct object

i.e. impl SyncProgress for Vec<SyncItem>

I see your point but in practice the SyncProgress will be used to just show the percent completed for these items and especially for mobile apps using language bindings transferring smaller and simpler structs is better.