BOLT 7: allow variable length onion messages.

But suggest constraining them to "small" or "large" sizings.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

Author: rustyrussell

07-routing-gossip.md

@@ -1140,7 +1140,8 @@ parameter which allows decryption of the `enctlv` field inside the
 
 1. type: 385 (`onion_message`) (`option_onion_messages`)
 2. data:
-    * [`1366*byte`:`onionmsg`]
+    * [`u16`:`len`]
+    * [`len*byte`:`onionmsg`]
     * [`onion_message_tlvs`:`onion_message_tlvs`]
 
 1. tlvs: `onion_message_tlvs`
@@ -1155,13 +1156,22 @@ The writer:
 - MUST populate the per-hop payloads as described in [BOLT 4](04-onion-routing.md#onion-messages).
 - SHOULD retry via a different route if it expects a response and
   doesn't receive one after a reasonable period.
+- SHOULD set `len` to 1366 or 32834.
 
 The reader:
 - MUST handle the per-hop payloads as described in [BOLT 4](04-onion-routing.md#onion-messages).
 - SHOULD accept onion messages from peers without an established channel.
 - MAY rate-limit messages by dropping them.
 
-## References
+## Rationale
+
+`len` allows larger messages to be sent than the standard 1300 bytes
+allowed for an HTLC onion, but this should be used sparingly as it is
+reduces anonymity set, hence the recommendation that it either look
+like an HTLC onion, or if larger, be a fixed size.
+
+
+# References
 
 1. <a id="reference-1">[RFC 1950 "ZLIB Compressed Data Format Specification version 3.3](https://www.ietf.org/rfc/rfc1950.txt)</a>
 2. <a id="reference-2">[Maximum Compression Factor](https://zlib.net/zlib_tech.html)</a>