Simplify on-chain fee management

[pm47]

Move away from the "block target" approach.

Get rid of the FeeEstimator abstraction and use an AtomicReference to store and update the current feerates, similar to the block count.

[codecov-commenter]

Codecov Report

Merging #2696 (b8f334e) into master (3a351f4) will decrease coverage by 0.08%.
The diff coverage is 89.84%.

❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.

@@            Coverage Diff             @@
##           master    #2696      +/-   ##
==========================================
- Coverage   85.86%   85.78%   -0.08%     
==========================================
  Files         215      215              
  Lines       17626    17637      +11     
  Branches      762      737      -25     
==========================================
- Hits        15134    15130       -4     
- Misses       2492     2507      +15     

Impacted Files	Coverage Δ
...n/scala/fr/acinq/eclair/json/JsonSerializers.scala	96.42% <ø> (ø)
...clair/channel/publish/ReplaceableTxPublisher.scala	71.95% <68.88%> (-2.25%)	⬇️
...re/src/main/scala/fr/acinq/eclair/NodeParams.scala	93.09% <83.33%> (-0.56%)	⬇️
...r/acinq/eclair/blockchain/fee/OnChainFeeConf.scala	93.33% <87.50%> (ø)
.../fr/acinq/eclair/channel/publish/TxPublisher.scala	97.50% <87.50%> (-1.24%)	⬇️
...la/fr/acinq/eclair/transactions/Transactions.scala	96.58% <92.30%> (ø)
...in/scala/fr/acinq/eclair/channel/fsm/Channel.scala	85.97% <94.73%> (+0.08%)	⬆️
...ir-core/src/main/scala/fr/acinq/eclair/Setup.scala	75.00% <100.00%> (-0.43%)	⬇️
...in/scala/fr/acinq/eclair/channel/Commitments.scala	96.75% <100.00%> (ø)
...c/main/scala/fr/acinq/eclair/channel/Helpers.scala	95.03% <100.00%> (ø)
... and 8 more

... and 6 files with indirect coverage changes

[pm47]

Rebased on master.

[pm47]

One thing left to address are the default feerates which I would really like to remove. I think there are two reasons for them to exist:

• as constant values for regtest (but we can directly use hardcoded values with a ConstantFeeProvider
• to deal with -1 values returned by estimatesmartfee in some corner cases (e.g. restart of bitcoin core)

Not sure exactly how to proceed though!

[t-bast]

This is looking good, much better than the previous block targets!

[t-bast]

Not sure exactly how to proceed though!

I don't know what we can do honestly, since we want to handle bitcoind restarts...I don't think we want to persist the latest fees, it's better to avoid a frequent DB call, so we need external input from the node operator (which is why hard-coded values in eclair.conf makes sense, even though it's not very satisfying).

[pm47]

Rebased.

[pm47]

Not sure exactly how to proceed though!

I don't know what we can do honestly, since we want to handle bitcoind restarts...I don't think we want to persist the latest fees, it's better to avoid a frequent DB call, so we need external input from the node operator (which is why hard-coded values in eclair.conf makes sense, even though it's not very satisfying).

Let's defer this to a later time.