Allow responding asynchronously to OnionMessage

[shaavan]

This PR addresses second part of #2882 and builds on #2907

This PR converts handle_onion_message_response into the public function which can be used for asynchronous response to a separately created ResponseInstruction.
Also, this introduces a new variant of ResponseInstruction. This allows creating a reply_path for the receiver while responding to their message.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 63.09524% with 31 lines in your changes are missing coverage. Please review.

Project coverage is 89.78%. Comparing base (d3cd080) to head (4ba91a9).
Report is 2 commits behind head on main.

❗ Current head 4ba91a9 differs from pull request most recent head 57bca64. Consider uploading reports for the commit 57bca64 to get more accurate results

Files	Patch %	Lines
lightning/src/onion_message/messenger.rs	40.38%	31 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2996      +/-   ##
==========================================
- Coverage   89.83%   89.78%   -0.05%     
==========================================
  Files         116      116              
  Lines       96465    96533      +68     
  Branches    96465    96533      +68     
==========================================
+ Hits        86657    86670      +13     
- Misses       7263     7310      +47     
- Partials     2545     2553       +8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[shaavan]

Updated from pr2996.01 to pr2996.02 (diff):

Update:

1. Synced with base PR (Introduce ResponseInstructions for OnionMessage Handling #2907) to solve merge conflicts.

[shaavan]

cc @jkczyz, @TheBlueMatt

[shaavan]

Updated from pr2996.02 to pr2996.03 (diff):
Addressed @jkczyz comments:

Updates:

1. Address nit comments.
2. Expanded return type of handle_onion_message_response. This change allows access to the success/failure status of sending the response to the user which they can handle appropriately.

[shaavan]

Updated from pr2996.03 to pr2996.04 (diff):

Updates:

1. Rebase on main, to resolve conflicts post Introduce ResponseInstructions for OnionMessage Handling #2907 merge.

[shaavan]

Updated from pr2996.04 to pr2996.05 (diff):
Addressed @TheBlueMatt, @jkczyz comments

Updates:

1. Expanded respond(), and respond_with_reply_path() documentation.
2. Updated test to check if we got the expected variant of SendSuccess, when calling handle_onion_message_response.
3. Refactor the code to improve brevity.
4. Update handle_onion_message response to fail in case we fail to create a blinded_path.
5. Fix the Fuzz test.

[shaavan]

Updated from pr2996.05 to pr2996.06 (diff):
Addressed @jkczyz comments

Updates:

1. Simplify the respond, and respond_with_reply_path docs to make them concise.
2. Simplify the result check in the added test.
3. Introduced logging in handle_onion_message_response if create_blinded_path fails to create reply_path.

[shaavan]

Updated from pr2996.06 to pr2996.07 (diff):

Updates:

1. Rebase on main, to fix ci failures.

[shaavan]

Updated from pr2996.07 to pr2996.08 (diff):
Addressed @TheBlueMatt and @jkczyz comments

Changes:

1. Expanded docs for respond and respond_with_reply_path so that there purpose is more clearly explained.
2. Expand log message to also contain the error itself.
3. nit blinded_path -> reply_path.
4. Simplified logger -> self.logger, since there are no context to add with the error message within the function.
5. Improve the code style to be more idiomatic.
6. Simplified format_args! -> format! for log_trace!

[jkczyz]

s/need/needs

[jkczyz]

We may actually want to inline this in both places using format_args!. Otherwise, we are allocating a string even if the user's log level doesn't trigger any logging.