3f7250b [test] Use the new endpoint to improve tests (Amiti Uttarwar)
3893da0 [RPC] Add field to getpeerinfo to indicate if addr relay is enabled (Amiti Uttarwar)
0980ca7 [test] Test that we intentionally select addr relay peers. (Amiti Uttarwar)
c061599 [net_processing] Remove RelayAddrsWithPeer function (Amiti Uttarwar)
201e496 [net_processing] Introduce new field to indicate if addr relay is enabled (Amiti Uttarwar)
1d1ef2d [net_processing] Defer initializing m_addr_known (Amiti Uttarwar)
6653fa3 [test] Update p2p_addr_relay test to prepare (Amiti Uttarwar)
2fcaec7 [net_processing] Introduce SetupAddressRelay (Amiti Uttarwar)

Pull request description:

  This PR builds on the test refactors extracted into #22306 (first 5 commits).

  This PR aims to reduce addr blackholes. When we receive an `addr` message that contains 10 or less addresses, we forward them to 1-2 peers. This is the main technique we use for self advertisements, so sending to peers that wouldn't relay would effectively "blackhole" the trickle. Although we cannot prevent this in a malicious case, we can improve it for the normal, honest cases, and reduce the overall likelihood of occurrence. Two known cases where peers would not participate in addr relay are if they have connected to you as a block-relay-only connection, or if they are a light client.

  This implementation defers initialization of `m_addr_known` until it is needed, then uses its presence to decide if the peer is participating in addr relay. For outbound (not block-relay-only) peers, we initialize the filter before sending the initial self announcement when processing their `version` message. For inbound peers, we initialize the filter if/when we get an addr related message (`ADDR`, `ADDRV2`, `GETADDR`). We do NOT initialize the filter based on a `SENDADDRV2` message.

  To communicate about these changes beyond bitcoin core & to (try to) ensure that no other software would be disrupted, I have:
  - Posted to the [mailing list](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018784.html)
  - Researched other open source clients to confirm compatibility, opened issues in all the projects & documented in #21528 (comment). Many have confirmed that this change would not be problematic.
  - Raised as topic during [bitcoin-core-dev meeting](https://www.erisian.com.au/bitcoin-core-dev/log-2021-03-25.html#l-954)
  - Raised as topic during [bitcoin p2p meeting](https://www.erisian.com.au/bitcoin-core-dev/log-2021-04-20.html#l-439)

ACKs for top commit:
  jnewbery:
    reACK 3f7250b
  glozow:
    ACK 3f7250b
  ajtowns:
    utACK 3f7250b

Tree-SHA512: 29069282af684c1cd37d107c395fdd432dcccb11626f3c2dabfe92fdc4c85e74c7c4056fbdfa88017fec240506639b72ac6c311f8ce7c583112eb15f47e421af

Summary:
```
This extends the functional test p2p_addr_relay.py.
It adds test coverage for address relay involving outbound peers, tests for both outgoing and incoming GETADDR requests and tests for -blocksonly mode.
```

Backport of [[bitcoin/bitcoin#21707 | core#21707]], [[bitcoin/bitcoin#21785 | core#21785]] (fix intermittent failure in the test) and [[bitcoin/bitcoin#22306 | core#22306]] (improvements to p2p_addr_relay.py, also fixes an intermittent issue).

Note to reviewers: you can look at the file after #22306 to get the final version of the test.

Depends on D10860.

Ref T1696.

Test Plan:
  ninja check-functional

Reviewers: #bitcoin_abc, PiRK

Reviewed By: #bitcoin_abc, PiRK

Subscribers: PiRK

Maniphest Tasks: T1696

Differential Revision: https://reviews.bitcoinabc.org/D10861