bolt04/09: add option_onion_messages_anywhere (feature 66/67)

[erickcestari]

Some senders look up nodes advertising option_onion_messages and assume they can relay through them without holding a channel. The spec only has a SHOULD for accepting onion messages from channelless peers, so a node that restricts acceptance to channel peers is still compliant yet silently drops those messages, with no feedback to the sender and no way for the sender to know in advance.

Introduce option_onion_messages_anywhere (66/67), depending on option_onion_messages, as the explicit opt-in for the channelless case: a node that advertises it MUST accept onion messages from any connected peer. The baseline option_onion_messages behavior is unchanged (still a SHOULD to accept from channelless peers), so this is backward compatible and does not forbid the lenient behavior nodes already implement.

This turns the pair into a deterministic signal: senders know exactly which nodes will accept a relay from a peer without a channel, rather than hoping a compliant node happens to be lenient.

---

OBS: An alternative design would redefine the baseline option_onion_messages to accept onion messages ONLY from channel peers, and make the new option_onion_messages_anywhere bit the extension that also accepts from peers without an established channel.

This is arguably cleaner: each bit maps to an exact, deterministic policy (channel peers only vs. anyone), which is less confusing than a SHOULD whose behavior a sender cannot predict.

The tradeoff is backward compatibility: CLN and LDK currently accept onion messages from channelless peers under the existing SHOULD, so tightening option_onion_messages to "channel peers only" would change their default behavior and could affect relays during the transition before the new bit is widely deployed.

This commit takes the additive route (keep option_onion_messages as a SHOULD, add option_onion_messages_anywhere as the MUST-accept opt-in) to avoid that churn, but the channel-peers-only framing is a reasonable alternative worth discussing if implementers prefer the clearer semantics.

[TheBlueMatt]

Given this is really intended as a short-term thing until onion messages are broadly supported, it seems really weird to make this a separate feature bit.

[t-bast]

I'm not a fan of introducing a new feature bit either, since I don't think it really improves reliability in practice. Senders should preferably go through a route that has channels anyway: if they can't find one, it will be a best effort and rate-limits may be strict, so even if nodes advertise option_onion_messages_anywhere it doesn't necessarily improve reliability.

The best improvement in practice for onion messages reliability will be when most nodes on the network do support it, at which point there will be a lot of routes with channels between nodes that can relay onion messages.

[erickcestari]

Given this is really intended as a short-term thing until onion messages are broadly supported, it seems really weird to make this a separate feature bit.

I don't think it's actually short-term. Even once onion messages are universal, accepting from channelless peers stays useful: a sender can inject from diverse entrypoints to try k different paths to the receiver instead of funneling everything through its own channeled peer, which matters when each hop adds some chance the message is rate-limited and dropped.

We also could avoid the new feature bit if we changed to a MUST route onion messages from channelless peers. But it would require changes in both LND and Eclair.