Dual funding channel confirmation

[t-bast]

Finalize the dual-funding flow: exchange signatures and wait for the funding transaction to confirm.

If an error occurs, we need to wait for the funding tx to be double-spent before we can consider the channel closed and safely forget it.

There is some logic duplication between single-funded and dual-funded handlers...I don't know how far we should go to try to remove duplication. If we extract too much, it may make it harder to just read an event handler's code and verify that every step is there and correctly done in the right order. Also, there are small subtleties where single-funded and dual-funded differ, and there will be more as we build new protocols on top of dual funding (e.g. liquidity ads). In the long term, we will eventually remove the code for the single-funded case, as it can be achieved as just a special case of dual-funding (but we'll need all peers on the network to support dual funding before we can really remove that). Let me know what you think and where you think we should refactor.

[codecov-commenter]

Codecov Report

Merging #2274 (f49116a) into master (33e6fac) will decrease coverage by 0.21%.
The diff coverage is 72.34%.

@@            Coverage Diff             @@
##           master    #2274      +/-   ##
==========================================
- Coverage   84.95%   84.74%   -0.22%     
==========================================
  Files         198      199       +1     
  Lines       15255    15455     +200     
  Branches      633      639       +6     
==========================================
+ Hits        12960    13097     +137     
- Misses       2295     2358      +63     

Impacted Files	Coverage Δ
...n/scala/fr/acinq/eclair/balance/CheckBalance.scala	64.89% <0.00%> (-1.42%)	⬇️
...inq/eclair/channel/fsm/SingleFundingHandlers.scala	80.00% <ø> (-4.10%)	⬇️
...main/scala/fr/acinq/eclair/db/DbEventHandler.scala	93.42% <ø> (ø)
...n/scala/fr/acinq/eclair/json/JsonSerializers.scala	95.12% <ø> (ø)
...in/scala/fr/acinq/eclair/channel/fsm/Channel.scala	84.80% <41.26%> (-2.67%)	⬇️
...q/eclair/channel/fsm/ChannelOpenSingleFunded.scala	93.80% <66.66%> (+0.12%)	⬆️
...acinq/eclair/channel/fsm/DualFundingHandlers.scala	62.16% <66.66%> (+5.01%)	⬆️
...inq/eclair/channel/fsm/ChannelOpenDualFunded.scala	91.15% <75.38%> (-5.91%)	⬇️
...c/main/scala/fr/acinq/eclair/channel/Helpers.scala	95.03% <88.88%> (+0.03%)	⬆️
...la/fr/acinq/eclair/channel/fsm/ErrorHandlers.scala	81.13% <88.88%> (+0.73%)	⬆️
... and 27 more

[t-bast]

I changed the watching behavior in bd47992 to correctly detect channel force-close while we're offline. The commit looks simple, but it's actually very subtle, please review carefully! The main subtlety is that we when we detect an alternative commitment being used, we don't claim it, we instead wait for the corresponding funding tx to be confirmed before acting. If we claimed it instantly and swapped the main commitments with this alternative one, we would be screwed if it's actually the main funding tx that ends up confirming...

I cannot add yet test cases for those alternative commitments since RBF isn't implemented, but it's on my TODO-list to add to the RBF PR.

[pm47]

Quick feedback to make sure we are on the same page with the new approach.

[pm47]

I'm pretty sure this works fine but I have still doubt about the OFFLINE/SYNCING case. Let's sleep on it 🤞.

[pm47]

Onto the next one! ⛵