Fix ability for plugins to exchange custom Lightning Messages with other LN nodes [PeerSwap]

[remyers]

These changes are a prerequisite for the PeerSwap plugin.

This PR introduces a potentially breaking change to existing plugins by changing how the codec parses unknown messages.

Custom Lightning Messages were previously assumed to be prepended with two-bytes for the size of the unknown message blob. Now unknown messages are assumed to be sent as just the custom message type followed by a blob of data, with no assumption that the first two bytes give the size of the following blob.

Unknown Lightning Messages sent to a channel will be forwarded to the channel peer if they are listed as a custom message used by a loaded plugin.

The change to unknownMessageCodec caused channelUpdateCodecWithType to incorrectly return success with an UnknownMessage, instead of failure. This was solved by using just the LightningMessageCodec instead of meteredLightningMessageCodec which fell back to UnknownMessage for invalid messages.

I also unsealed TransactionWithInputInfo so that plugins can use checkSpendable with custom on-chain transactions.

[thomash-acinq]

Custom Lightning Messages were previously assumed to be prepended with two-bytes for the size of the unknown message blob. Now unknown messages are assumed to be sent as just the custom message type followed by a blob of data, with no assumption that the first two bytes give the size of the following blob.

This is an assumption of TLVs, does it mean that you're using messages that are not TLVs? Why?

[remyers]

This is an assumption of TLVs, does it mean that you're using messages that are not TLVs? Why?

The length is still implicitly encoded, none of the other Lightning Message codecs explicitly encode the length of the payload like codecUnknownMessage did before this change.

[thomash-acinq]

The length is still implicitly encoded, none of the other Lightning Message codecs explicitly encode the length of the payload like codecUnknownMessage did before this change.

It looked like a TLV at first glance but you're right, it's not, so the tag doesn't have to be followed by a size.

[codecov-commenter]

Codecov Report

Merging #2495 (a6e6527) into master (9ae4dea) will increase coverage by 0.02%.
The diff coverage is 90.90%.

@@            Coverage Diff             @@
##           master    #2495      +/-   ##
==========================================
+ Coverage   84.98%   85.01%   +0.02%     
==========================================
  Files         198      200       +2     
  Lines       15839    15833       -6     
  Branches      682      675       -7     
==========================================
- Hits        13461    13460       -1     
+ Misses       2378     2373       -5     

Impacted Files	Coverage Δ
...rc/main/scala/fr/acinq/eclair/io/Switchboard.scala	84.61% <66.66%> (-1.10%)	⬇️
...-core/src/main/scala/fr/acinq/eclair/io/Peer.scala	89.64% <100.00%> (+0.16%)	⬆️
...fr/acinq/eclair/wire/protocol/FailureMessage.scala	83.56% <100.00%> (+0.46%)	⬆️
.../eclair/wire/protocol/LightningMessageCodecs.scala	99.35% <100.00%> (-0.65%)	⬇️
...-core/src/main/scala/fr/acinq/eclair/package.scala	74.28% <0.00%> (-8.41%)	⬇️
...q/eclair/channel/publish/ReplaceableTxFunder.scala	85.18% <0.00%> (-1.73%)	⬇️
...cinq/eclair/payment/receive/MultiPartHandler.scala	93.65% <0.00%> (-0.65%)	⬇️
...cala/fr/acinq/eclair/crypto/TransportHandler.scala	90.60% <0.00%> (-0.56%)	⬇️
...in/scala/fr/acinq/eclair/channel/fsm/Channel.scala	86.27% <0.00%> (ø)
... and 17 more

[remyers]

This issue of whether or not to include the type prefix is resolved in BOLT 4 PR #979. We should be able to remove parsing of historical failure messages with un-prefixed channel_updates.

[remyers]

Is there a way to find out how many failure messages we get that are missing the type prefix for the embedded channel_update? It would be nice to remove entirely the ambiguity in parsing failure messages now that the spec is updated.

[tnull]

Is there a way to find out how many failure messages we get that are missing the type prefix for the embedded channel_update? It would be nice to remove entirely the ambiguity in parsing failure messages now that the spec is updated.

I would also be interested in some numbers, as I'd like to be able to remove said parsing ambiguity from LDK/rust-lightning. However, I assume it's not ready yet, as LND still doesn't seem to write the type prefix?: lightningnetwork/lnd#6461

[t-bast]

LGTM, only a couple of nits