More specific.

This context will be used in reply paths for outbound held_htlc_available
messages, so we can authenticate the corresponding release_held_htlc messages.

Useful for using the payment_id within to look up the corresponding outbound
async payment so we know we can safely release the HTLCs to the now-onlinen
recipient.

Upcoming commits will support sending and receiving held_htlc_available and
release_held_htlc messages. These messages need to be enqueued so that they can
be released in ChannelManager's implementation of AsyncPaymentsMessageHandler
to OnionMessenger for sending.

Useful for ensuring that an inbound static invoice matches one of our outbound
invreqs, otherwise it is an unexpected invoice and should be ignored and not
paid.

Adds a pending outbound payment variant for async payments, which indicates
that we have received a static invoice to pay and have generated a keysend preimage
for the eventual payment. When the recipient comes back online, we'll
transition from this new state to Retryable and actually forward the HTLCs.

Allows us to repurpose this util to create blinded paths in an async payments
message context while maintaining support for the offers context.

Supported when the sender is an always-online node. Here we send the initial
held_htlc_available onion message upon receipt of a static invoice, next we'll
need to actually send HTLCs upon getting a response to said OM.

Because we may receive a static invoice to pay days before the recipient
actually comes back online to receive the payment, it's good to do as many
checks as we can up-front. Here we ensure that the blinded paths provided
in the invoice won't cause us to exceed the maximum onion packet size.

This new util will be able to send to both static and non-static BOLT 12
invoices.

Async receive is not yet supported.

Here we process inbound release_htlc onion messages, check that they actually
correspond to one of our outbound payments, and actually forward the HTLCs.
Valid release_htlc receipt indicates that the recipient has now come online to
receive.

Async payments may have very high expires because we may be waiting for days
for the recipient to come online, so it's important that users be able to
abandon these payments early if needed.

If someone sends us an unexpected or duplicate release_held_htlc onion message,
we should simply ignore it and not persist the entire ChannelManager in
response.

We want to specify that these methods are only to be used in an outbound offers
payment context, because we'll be adding similar methods for the outbound async
payments context in upcoming commits.

See AsyncPaymentsContext::hmac, but this prevents the recipient from
deanonymizing us. Without this, if they are able to guess the correct payment
id, then they could create a blinded path to us and confirm our identity.

We also move the PAYMENT_HASH_HMAC_INPUT const to use &[7; 16], which is safe
because this const was added since the last release. This ordering reads more
smoothly.

Currently used when initiating an async payment via held_htlc_available OM. This
OM needs a reply path back to us, so use this error for our invoice_error OM if
we fail to create said reply path.

While these variants may sound similar, they are very different. One is so
temporary it's never even persisted to disk, the other is a state we will stay
in for hours or days. See added docs for more info.

This field isn't necessary because we already authenticate the messages via the
blinded reply paths payment_id, nonce and HMAC.