Always forward gossip for all our channels to all our peers

[TheBlueMatt]

Sadly, the lightning gossip protocol operates by always flooding
peers with all the latest gossip they receive. For nodes with many
peers, this can result in lots of duplicative gossip as they
receive every message from every peer. As a results, some lightning
implementations disable gossip with new peers after some threshold.
This should mostly work as these peers expect to receive the latest
gossip from their many other peers.

However, in some cases an LDK node may wish to open public
channels but only has a single connection to the bulk of the  rest
of the network - with one such peer which requests that it not
receive any gossip. In that case, LDK would dutifully never send
any gossip to its only connection to the outside world. We would
still send gossip for channels with that peer as it would be sent
as unicast gossip, but if we then open another connection to
another peer which doesn't have any connection to the outside world
any information on that channel wouldn't propagate.

We've seen this setup on some LSPs, where they have a public node
and then an LSP which only connects through that public node, but
expects to open public channels to its LSP clients.

Here we finally forward all gossip that is about either side of any
of our channels to all our peers, irrespective of their requested
gossip filtering.

[ldk-reviews-bot]

👋 Thanks for assigning @wpaulino 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.

[wpaulino]

Looks like this was spelled out in the spec already:

This assumption of adequate propagation does not apply for gossip messages generated directly by the node itself, so they should ignore filters.

LGTM, though some test coverage would be nice.

[codecov]

Codecov Report

❌ Patch coverage is 90.21739% with 18 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.33%. Comparing base (e42e74e) to head (f39a230).
⚠️ Report is 16 commits behind head on main.

Files with missing lines	Patch %	Lines
lightning/src/ln/peer_handler.rs	90.00%	11 Missing and 1 partial ⚠️
lightning/src/routing/gossip.rs	83.33%	2 Missing and 1 partial ⚠️
lightning-net-tokio/src/lib.rs	0.00%	2 Missing ⚠️
lightning/src/routing/utxo.rs	80.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##             main    #4216    +/-   ##
========================================
  Coverage   89.33%   89.33%            
========================================
  Files         180      180            
  Lines      138055   138222   +167     
  Branches   138055   138222   +167     
========================================
+ Hits       123326   123483   +157     
- Misses      12122    12130     +8     
- Partials     2607     2609     +2     

Flag	Coverage Δ
fuzzing	33.64% <57.42%> (+0.06%)	⬆️
tests	88.71% <85.86%> (-0.01%)	⬇️

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.

[TheBlueMatt]

This is more than just that - we're also forwarding gossip from our peers for our channels. Will ask an LLM to add coverage.

[TheBlueMatt]

Claude kinda wrote a test...of course the test it generated passed the checks entirely by accident and didn't actually test the new logic, but it was a start lol.