p2p: Don't require services from `ADDR_FETCH` peers #26343

While testing #20018, I noticed that we sometimes make an AddrFetch connection to a node a DNS seed resolves to (if we have a -proxy set), but then disconnect them because we don't like their services. The same could happen for a manually added -seednode. However, we only want addresses from these peers, which are not related to any of the current service flags, so I don't see a point in aborting an AddrFetch attempt due to undesirable services.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

No conflicts as of last run.

However, we only want addresses from these peers, which are not related to any of the current service flags, so I don't see a point in aborting an AddrFetch attempt due to undesirable services.

MayHaveUsefulAddressDB makes me think we that we are assuming nodes signaling NODE_NETWORK or NODE_NETWORK_LIMITED to have a useful addr db.

https://github.com/bitcoin/bitcoin/blob/2ac71d20b2ebbfea76ee7369fddffbd78bd2c010/src/protocol.h#L352-L359

MayHaveUsefulAddressDB makes me think we that we are assuming nodes signaling NODE_NETWORK or NODE_NETWORK_LIMITED to have a useful addr db.

Interesting! I guess we could leave ExpectServicesFromConn as is but check for MayHaveUsefulAddressDB() instead of HasAllDesirableServiceFlags() for an AddrFetch connections when deciding whether to accept the peer.

However, I'm not sure this would be ideal, for the following reasons:

• MayHaveUsefulAddressDB is used to decide whether we want to connect to a feeler, and whether to process a received addr at all. In neither of these situations we particularly care about the peer's address db (we don't even request addrs from feelers), we care whether it is a (pruned or not) full node, so the function might better be named IsFullNode().
• MayHaveUsefulAddressDB just makes the assumption that SPV clients don't know about address relay when they can't serve blocks - that may be the case for most current software, but I don't see why a SPV node shouldn't implement addr relay.
• When we do an AddrFetch connection, we usually don't have a bunch of alternative addrs (otherwise there would be no need to make such a connection in the first place) - we either manually specified this peer (-seednode), it's a peer a DNS seed resolves to, or (if #26114 makes it in) it's a fixed seed. When we do make an AddrFetch connection and the peer doesn't deliver addrs, we disconnect them after a few minutes. So I can't see the hurt in trying, even if the service bits don't match, if we don't have a better alternative.

closing, there doesn't seem to be much interest and even though I still think it could make sense, it's certainly not critical.