Add initial support for async payment trampoline relay

[remyers]

This is the first step in adding "async payments" as described in issue #2424 .

[remyers]

Some Questions for my next set of changes to this PR:

• What information should go in the AsyncPaymentFeatures onion tlv?

I currently use invoice feature bits because an empty tlv seemed wrong. The sender will look for the AsyncPaymentPrototype feature bit in the invoice, but the trampoline relay does not have access to the invoice (for privacy). That's why the sender must add a tlv specifically to the onion of the trampoline relay.

• When I change the AsyncPaymentTrigger message to be a non-spec LightningMessage that is routed to the NodeRelayer, should it be keyed off of the nodeRelayPacket.outerPayload.paymentSecret for the node relayer ?

• Would it be better to publish an event when an AsyncPaymentTrigger non-spec LightningMessage is received, or route it to the set of running NodeRelayer actors ?

[codecov-commenter]

Codecov Report

Merging #2435 (f670676) into master (ba2b928) will increase coverage by 0.15%. The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #2435      +/-   ##
==========================================
+ Coverage   84.71%   84.86%   +0.15%     
==========================================
  Files         199      198       -1     
  Lines       15748    15796      +48     
  Branches      656      680      +24     
==========================================
+ Hits        13341    13406      +65     
+ Misses       2407     2390      -17     

Impacted Files	Coverage Δ
.../scala/fr/acinq/eclair/payment/PaymentEvents.scala	97.61% <ø> (ø)
.../scala/fr/acinq/eclair/payment/relay/Relayer.scala	89.13% <ø> (ø)
...core/src/main/scala/fr/acinq/eclair/Features.scala	99.27% <100.00%> (+0.02%)	:arrow_up:
...re/src/main/scala/fr/acinq/eclair/NodeParams.scala	93.26% <100.00%> (+0.12%)	:arrow_up:
...cala/fr/acinq/eclair/payment/relay/NodeRelay.scala	96.55% <100.00%> (+0.61%)	:arrow_up:
...a/fr/acinq/eclair/wire/protocol/PaymentOnion.scala	99.25% <100.00%> (+0.02%)	:arrow_up:
...acinq/eclair/channel/fsm/DualFundingHandlers.scala	80.43% <0.00%> (-2.18%)	:arrow_down:
...scala/fr/acinq/eclair/router/BalanceEstimate.scala	98.91% <0.00%> (-1.09%)	:arrow_down:
...main/scala/fr/acinq/eclair/io/PeerConnection.scala	86.02% <0.00%> (-0.37%)	:arrow_down:
...in/scala/fr/acinq/eclair/channel/fsm/Channel.scala	86.16% <0.00%> (-0.12%)	:arrow_down:
... and 11 more

[remyers]

RE: @t-bast 's point earlier about the possibility of a channel closure if the receiver does not trigger the payment and the sender is not back online within cancel-safety-before-timeout-blocks of when it times out.

An async payment sender should probably set the payment expiry well beyond their LSP's expected hold-timeout-blocks (default: 1008 blocks, ~7 days). If the default async payment expiry was something like twice the default hold-timeout-blocks, then the sender would need to be online once within a 6 day period before the payment expires to prevent a channel closure. They would also have a 7 day period before the LSP's timeout to manually cancel the payment.