security(net): Stop sending peer addresses from handshakes directly to the address book

[teor2345]

Motivation

We want to stop sending connection addresses directly to the address book, because that's insecure.

Close #7951

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.

Complex Code or Requirements

This is actually simpler than the previous code, because it doesn't have concurrency issues with other updates for the same address.

Using gossiped addresses changes the outbound connection priority slightly.

Solution

• Send handshake peer addresses to the per-connection address cache
• Update documentation

Testing

@arya2 what tests should we write here?
Is inspection enough, or should we have a "not sent to the address book" or "sent to the cache" test?

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.

Follow Up Work

There are some cleanups in #7824 that depend on this.

[upbqdn]

All changes in this PR look good to me, so I'm approving. However, I don't know the implications of sending handshake peer addresses to the per-connection address cache.

[teor2345]

However, I don't know the implications of sending handshake peer addresses to the per-connection address cache.

This PR prevents two attacks:

• peers modifying each others' addresses using version messages
• peers filling the address book by repeatedly connecting and sending different addresses in each version message

Here are some potential drawbacks:

• We might lose these addresses when the peer sends an addr message (but addr messages should always contain that peer's address, so in some cases we might lose the remote address of inbound connections). This is fixed in security: Limit how many addresses we use from each peer address message #7952 by adding all new addresses to the cache, taking any that are needed, then truncating the rest if needed.
• These addresses are treated like gossiped addresses, so they have slightly higher priority. This is unlikely to have a significant impact, because their times will quickly become outdated by new addresses from this peer or other peers.

[teor2345]

The macOS job seems to have failed due to a GitHub runner error, this is an issue with their infrastructure. There is no output in the failed steps on the GUI or in the raw logs, there's just this:

2023-11-23T13:58:23.3683400Z Requested labels: macos-latest
2023-11-23T13:58:23.3683747Z Job defined at: ZcashFoundation/zebra/.github/workflows/ci-unit-tests-os.yml@refs/pull/7977/merge
2023-11-23T13:58:23.3683911Z Waiting for a runner to pick up this job...
2023-11-23T13:58:25.8364996Z Job is waiting for a hosted runner to come online.
2023-11-23T13:58:29.5183703Z Job is about to start running on the hosted runner: GitHub Actions 22 (hosted)

https://github.com/ZcashFoundation/zebra/actions/runs/6970673248/job/18969099332?pr=7977