Onion message follow-ups

[valentinewallace]

• Force users to use path_id
• Enable the addition of dummy blinded hops for increased privacy
• On creation, pad blinded route hops to be equal length
• Support 1-hop blinded paths
• Rate limit based on channel vs non-channel peers
• Rate limit based on outbound peer buffer limits
• Refuse to send onion messages to offline peers and drop forwards to offline peers
• Config option for forwarding over channels-only
• Custom TLVs, sending-side + handler on receiving side
• Implement BOLT spec test vectors
• Consider setting max number of hops before refusing to send
• Custom get_route for finding an OM path (current get_route has a lot of custom stuff for payments)
• Flip on OM feature bit (may want to conditionally flip based on whether a user has an OnionMessenger)
• Refactor onion_utils::construct_onion_packet_with_init_noise to take one Vec instead of two
• Minor: make onion_utils::decode_next_hop private, see Onion messages v1 #1503 (comment)
• Add fuzz testing
• Don't disconnect peers on garbage onion messages (cc Onion messages v1 #1503 (comment))

[TheBlueMatt]

Support receiving onion messages to phantom nodes.

[valentinewallace]

Support receiving onion messages to phantom nodes.

cc #1503 (comment)

[TheBlueMatt]

Need to have a fuzzer for reading/decoding/forwarding onion messages before we can ship it, I think.

[TheBlueMatt]

Maybe clean up API a bit, re #1503 (comment)

[valentinewallace]

Due to recent spec updates forcing the use of blinded paths, we'll want to support 1-hop blinded paths now too.

[carlaKC]

If nobody is working on it, I'd like to attempt adding the OM test vectors - as requested here.

[TheBlueMatt]

We should presumably include padding (someone taking over #1771) no?

[valentinewallace]

We should presumably include padding (someone taking over #1771) no?

Yeah, that would be good. That's included in the issue already, if that's what you mean.