Add remote_addr field to lightning_net_tokio::setup_outbound

[tankyleo]

    Add `remote_addr` field to `lightning_net_tokio::setup_outbound`

    When `setup_outbound` was used to setup a connection proxied over Tor,
    it previously set `remote_addr` to the address of the Tor proxy, and not
    the address of the peer on the other side of the stream.

    The address of the Tor proxy was assigned to the
    `PeerDetails::socket_address` for that peer in
    `PeerManager::list_peers`, and if it was not a private IPV4 or IPV6
    address, it was also reported to the peer in our init message.

    Here we ask callers of `setup_outbound` to pass a `remote_addr`
    separately from the `StdTcpStream`. `connect_outbound` sets this new
    `remote_addr` parameter to `get_addr_from_stream`, and
    `tor_connect_outbound` passes its own `addr` parameter directly to
    `remote_addr`.

    Notably, Onion V3 addresses will now appear in `PeerManager::list_peers`
    for outbound Tor connections to Onion V3 services made using
    `tor_connect_outbound`, and will be reported to the peer in our init
    message.

    While this adds a new parameter to the public `fn setup_outbound`
    function, this closely mirrors the existing public method
    `PeerManager::new_outbound_connection`.

[ldk-reviews-bot]

👋 Thanks for assigning @tnull as a reviewer!
I'll wait for their review and will help manage the review process.
Once they submit their review, I'll check if a second reviewer would be helpful.

[tankyleo]

Fixes the issues @jharveyb reported in lightningdevkit/ldk-node#778

[codecov]

Codecov Report

❌ Patch coverage is 66.66667% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 86.02%. Comparing base (8679d8d) to head (28cf5f5).
⚠️ Report is 43 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning-net-tokio/src/lib.rs	66.66%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4372      +/-   ##
==========================================
+ Coverage   85.98%   86.02%   +0.03%     
==========================================
  Files         156      156              
  Lines      102641   103012     +371     
  Branches   102641   103012     +371     
==========================================
+ Hits        88258    88615     +357     
- Misses      11873    11889      +16     
+ Partials     2510     2508       -2     

Flag	Coverage Δ
tests	86.02% <66.66%> (+0.03%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tnull]

Generally makes sense. One question, otherwise CI seems unhappy right now.

[tnull]

Hmm, rather than adding this on the generic setup_outbound, would it make sense to refactor this to be an setup_outbound_internal and offer two setup_outbound and setup_outbound_tor variants that do the right (tm) thing for the user? Or, put differently, for non-Tor users this remote_addr argument might be confusing?

[tankyleo]

Let me know how this sounds below tnull, I avoid adding a setup_outbound_tor, and call setup_outbound_internal directly from connect_outbound_tor. I'd prefer to avoid adding a new function unless we really have to.

[TheBlueMatt]

Agree with @tnull otherwise lgtm

[tnull]

Changes look good, but it would be great if we could add some kind of test coverage (maybe even based on the _internal method to check that the override works as expected?

[tnull]

Hmm, asserting on log messages is often a bit error prone. Shouldn't we rather assert that the counterparty's PeerManager::list_peers reports the expected value?