Document example code or add helper code for fee estimation

[notmandatory]

Describe the enhancement

In the pre-1.0.0 BDK APIs the Blockchain.estimate_fee API provided a thin wrapper around blockchain clients native calls. Since the Blockchain trait is not needed anymore we need a new way to help users estimate transaction fees.

A couple options are:

1. Document how to call the native blockchain client's methods for fee estimation.

electrum-client:

FeeRate::from_btc_per_kvb(client.estimate_fee(target)? as f32)

esplora-client BlockingClient:

let estimates = client.get_fee_estimates()?;
FeeRate::from_sat_per_vb(esplora-client::convert_fee_rate(target, estimates,)?)

eplora-client AsyncClient:

let estimates = client.get_fee_estimates().await?;
FeeRate::from_sat_per_vb(esplora-client::convert_fee_rate(target, estimates,)?)

bitcoincore_rpc:

let sat_per_kb = client
      .estimate_smart_fee(target as u16, None)?
      .fee_rate
      .ok_or(Error::FeeRateUnavailable)?
      .to_sat() as f64;
FeeRate::from_sat_per_vb((sat_per_kb / 1000f64) as f32))

2. Add some sort of new FeeEstimator trait with implementations for each of the above. Could also add implementations for popular providers custom APIs like mempool.space.

Use case

Getting the fee rate is a common operation most bdk based apps will need. It is also something that pre-1.0 BDK provided and if missing could slow down users migrating to the 1.0.

Additional context

This issue was discussed in #1052 by @tnull and in bitcoindevkit/.github#70 and on Discord.

[vladimirfomene]

Nakamoto has a way of estimating feerate per block. https://docs.rs/nakamoto-client/0.4.0/nakamoto_client/enum.Event.html#variant.FeeEstimated. I don't yet know how we could use that information for feerate calculation in the case of CBF, but I will definitely look into it.

[sebastianmontero]

In my opinion it would be great to have a trait that abstracts away the implementation details of each of the clients.

[realeinherjar]

I also think that having traits to abstract details is the way to go. It is also more future-proof as well.

[LLFourn]

Before adding a trait can we use the fee estimation in all the examples.