Merge bitcoin/bitcoin#22778: net processing: Reduce resource usage for inbound block-relay-only connections

9db82f1 [net processing] Don't initialize TxRelay for non-tx-relay peers. (John Newbery)
b0a4ac9 [net processing] Add m_tx_relay_mutex to protect m_tx_relay ptr (John Newbery)
290a8da [net processing] Comment all TxRelay members (John Newbery)
42e3250 [net processing] [refactor] Move m_next_send_feefilter and m_fee_filter_sent (John Newbery)

Pull request description:

  block-relay-only connections are additional outbound connections that bitcoind makes since v0.19. They participate in block relay, but do not propagate transactions or addresses. They were introduced in #15759.

  When creating an outbound block-relay-only connection, since we know that we're never going to announce transactions over that connection, we can save on memory usage by not a `TxRelay` data structure for that connection. When receiving an inbound connection, we don't know whether the connection was opened by the peer as block-relay-only or not, and therefore we always construct a `TxRelay` data structure for inbound connections.

  However, it is possible to tell whether an inbound connection will ever request that we start announcing transactions to it. The `fRelay` field in the `version` message may be set to `0` to indicate that the peer does not wish to receive transaction announcements. The peer may later request that we start announcing transactions to it by sending a `filterload` or `filterclear` message, **but only if we have offered `NODE_BLOOM` services to that peer**. `NODE_BLOOM` services are disabled by default, and it has been recommended for some time that users not enable `NODE_BLOOM` services on public connections, for privacy and anti-DoS reasons.

  Therefore, if we have not offered `NODE_BLOOM` to the peer _and_ it has set `fRelay` to `0`, then we know that it will never request transaction announcements, and that we can save resources by not initializing the `TxRelay` data structure.

ACKs for top commit:
  MarcoFalke:
    review ACK 9db82f1 🖖
  dergoegge:
    Code review ACK 9db82f1
  naumenkogs:
    ACK 9db82f1

Tree-SHA512: 83a449a56cd6bf6ad05369f5ab91516e51b8c471c07ae38c886d51461e942d492ca34ae63d329c46e56d96d0baf59a3e34233e4289868f911db3b567072bdc41

Author: fanquake