security: Limit how many addresses we use from each peer address message

[teor2345]

Motivation

We want to limit how many addresses we use from each peer, so that our outbound connections are based on peers shared by most of our peers.

Close #1869

PR Author Checklist

Check before marking the PR as ready for review:

• Will the PR name make sense to users?
• Does the PR have a priority label?
• Have you added or updated tests?
• Is the documentation up to date?

For significant changes:

• Is there a summary in the CHANGELOG?
• Can these changes be split into multiple PRs?

If a checkbox isn't relevant to the PR, mark it as done.

We might want to have an overall changelog entry for the tracking issue, but it doesn't need to be added here.

Complex Code or Requirements

We need to limit in two places: existing cached peers, and responses based on a request. These limits operate slightly differently, because only a new response can cause an overflow.

Solution

• When we have cached peers, only take some of them to answer a request
• When we send a peer request, only take some of the response to answer a request, and put the rest in the cache
• In response to unsolicited address messages, add the latest addresses to the cache, and discard the oldest ones
• Choose response addresses at random
• Update outdated docs referring to this ticket

Testing

Add a new proptest for the cache update method.

The remaining parts of the PR are simple and can be checked by manual review, or by existing tests (including integration tests).

Review

This is a routine fix.

Reviewer Checklist

Check before approving the PR:

• Does the PR scope match the ticket?
• Are there enough tests to make sure it works? Do the tests cover the PR motivation?
• Are all the PR blockers dealt with?
  PR blockers can be dealt with in new tickets or PRs.

And check the PR Author checklist is complete.

[mpguerra]

Is this PR linked to #1869 ?

[teor2345]

Is this PR linked to #1869 ?

Yes, I've updated the ticket.

[arya2]

This looks great!

I opened an optional suggestion PR (#7960), but this is good to merge as-is, feel free to remove the do-not-merge tag and close #7960 if you disagree with the suggestion.

[teor2345]

This looks great!

I opened an optional suggestion PR (#7960), but this is good to merge as-is, feel free to remove the do-not-merge tag and close #7960 if you disagree with the suggestion.

I am happy to deal with #7960 separately. (Since it is an optional suggestion, this PR does not need to be blocked by it.)