Use remote funding when setting max_htlc_value_in_flight

[t-bast]

When using dual-funding, both peers may contribute to the funding amount and it usually cannot be known ahead of time how much the remote peer will contribute, which usually leads to underestimating the channel capacity and thus using a lower max_htlc_value_in_flight than what should be used.

However, when we use liquidity ads, we will:

• contribute to the funding transaction if we're not the opener
• cancel the funding attempt if we're the opener and our peers doesn't contribute at least the amount we requested

So in that case, we can use a better estimate of the channel capacity when computing our max_htlc_value_in_flight.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 85.97%. Comparing base (12df4ce) to head (a31fd1b).
Report is 4 commits behind head on master.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2980      +/-   ##
==========================================
- Coverage   86.02%   85.97%   -0.05%     
==========================================
  Files         227      228       +1     
  Lines       20371    20442      +71     
  Branches      815      837      +22     
==========================================
+ Hits        17524    17575      +51     
- Misses       2847     2867      +20     

Files with missing lines	Coverage Δ
...la/fr/acinq/eclair/io/OpenChannelInterceptor.scala	91.48% <100.00%> (+0.24%)	⬆️

... and 11 files with indirect coverage changes

[t-bast]

@remyers ping 🙏

[remyers]

LGTM!

Changes look good and tested. My only question is why this value can't be updated later.

I think the answer is that this value is only exchanged once when the channel is opened (or spliced) and there just isn't a mechanism to update it short of a splice. It also limits the htlc_maximum_msat in channel_update and channel_announcement so even if it were updated after the open there would be a period of time after the initial announcement when the full capacity couldn't be used.

Am I understanding this correctly?

[t-bast]

I think the answer is that this value is only exchanged once when the channel is opened (or spliced) and there just isn't a mechanism to update it short of a splice.

Exactly, this currently cannot be updated in the protocol. That's one of the goal of dynamic commitments.