BOLT1: Add support for network message padding (feature ??)

[tnull]

Previous research 1, 2 has shown that the Lightning Network is susceptible to passive network-layer attacks on privacy that can exploit metadata leaking from transmitted network messages.

While other factors such as timing come into play, the most severe information leakage is due to the fact that a passive adversary monitoring the Noise-encrypted network traffic can still observe clearly distinguished network message sizes, which allows them to reliably classify messages by type, and therefore in turn allows them to draw conclusions on node behavior. In the worst case, this allows a purely passive off-path adversary able to monitor traffic of multiple nodes on a payment path to not only observe that a payment took place, but also to identify the payment's endpoints.

To mitigate the information leakage coming from observable network message sizes, we here propose the introduction of option_message_padding, a simple protocol that allows Lightning counterparties to opt into padding network messages to fixed size thresholds large enough to cover update_add_htlc messages by including suitably sized TLV records in all sent TLV stream extensions.

This approach will lead to uniform message size distribution for 'normal' day-to-day operations. Note however that messages beyond the chosen size threshold will still stand out and leak some amount of information. Moreover, note that we abstained from including padding for custom messages, as it's not guaranteed that all application-layer protocols are able to handle TLV streams according to 'it's-okay-to-be-odd' rules (see #1302 for some questions around that).

A draft of a reference implementation can be found over at lightningdevkit/rust-lightning#4248

Some sidenotes on the chosen approach/current PR:

• The absence of network message padding could be considered a shortcoming of the BOLT8 transport / Noise encryption protocol. Therefore, we could also consider adding a new Noise handshake version for it and adding the padding on this layer. While this could be considered the cleaner approach, I previously received feedback from a few people that they would prefer the optional-TLV-approach proposed in this PR, which is why I went this way for now. I however would be open to discuss either approach - maybe making it a (mandatory?) part of BOLT8 would be cleaner. In particular, it would also allow us to add padding for custom messages, which the current approach doesn't necessarily allow.
• While the current proposal states that the receiver should discard the padding bytes, we could consider making use of the padding TLV, e.g., to opportunistically transmit enqueued gossip data. While this extension could result in a nice reduction of net overhead, I for now left it out of the proposal.
• For now I set feature 68/69 as a placeholder as they look to be the next free ones, but I might be missing something.