Enqueue onion messages in handlers
authorJeffrey Czyz <jkczyz@gmail.com>
Thu, 14 Sep 2023 02:19:50 +0000 (21:19 -0500)
committerJeffrey Czyz <jkczyz@gmail.com>
Wed, 18 Oct 2023 23:31:16 +0000 (18:31 -0500)
commit8b442fe4eb80ee43121c3a0f7a364698a296b713
tree104b0623af3170b8878a702c1886bae04bc049cc
parent840efd533468cf7cacd8b4bab27ce2db86b3eb93
Enqueue onion messages in handlers

When constructing onion messages to send initially (opposed to replying
to one from a handler), the user must construct an OnionMessagePath first
before calling OnionMessener::send_onion_message. Additionally, having a
reference to OnionMessener isn't always desirable. For instance, in an
upcoming commit, ChannelManager will implement OffersMessageHandler,
which OnionMessenger needs a reference to. If ChannelManager had a
reference to OnionMessenger, too, there would be a dependency cycle.

Instead, modify OffersMessageHandler and CustomOnionMessageHandler's
interfaces to include a method for releasing pending onion messages.
That way, ChannelManager may, for instance, construct and enqueue an
InvoiceRequest for sending without needing a reference to
OnionMessenger.

Additionally, OnionMessenger has responsibility for path finding just as
it does when replying to messages from a handler. It performs this when
extracting messages from the handlers before returning the next message
to send to a peer.
fuzz/src/onion_message.rs
lightning/src/ln/peer_handler.rs
lightning/src/onion_message/functional_tests.rs
lightning/src/onion_message/messenger.rs
lightning/src/onion_message/mod.rs
lightning/src/onion_message/offers.rs