GetExtraFullOutboundCounts counts reconciliation peers against the full-relay budget too

This description is AI generated, mistakes can be made.

Intent: Break the rule that each type is evicted against its own budget. With a full complement of recon peers, the node always thinks it has extra full-relay peers. The case for high: the node keeps evicting full-relay peers and keeps clearing the stale-tip extra-peer flag, which weakens eclipse defences.

Behaviour change: Original: with 8 full-relay and 4 recon peers, extra.full_relay == 0. Mutant: extra.full_relay == 4, so every CheckForStaleTipAndEvictPeers round (about every 45s) evicts the youngest eligible full-relay peer and calls SetTryNewOutboundPeer(false). ThreadOpenConnections then reopens a full-relay slot, so full-relay peers churn without end.

Trigger: Run a mainnet node with -txreconciliation. Once it has 8 OUTBOUND_FULL_RELAY and 4 OUTBOUND_FULL_RECONCILIATION peers that have completed the handshake and are older than MINIMUM_CONNECT_TIME, each eviction round disconnects one full-relay peer.

Spec violation: net_processing.cpp comment: 'Each type is evicted against its own budget: evicting across budgets would not help, since ThreadOpenConnections would just reopen a connection of the evicted type'

Severity if undetected: medium

Why tests miss it: denialofservice_tests.cpp (reconciliation_peer_eviction: 6 full outbound in total, which is <= 8; eviction_keeps_a_connection_per_network: already over by 1, and one eviction per round either way; stale_tip_peer_management*: no recon peers); fuzz/connman.cpp only calls the function; rg GetExtraFullOutboundCounts

Plausibility: The line before the PR was IsFullOutboundConn(), and the header doc says that helper covers 'both fanout and reconciliation'. Using it for the 'full relay' counter reads naturally.

Equivalence risk: It only differs when recon peers plus full-relay peers exceed 8. That is the normal state of a node with -txreconciliation on, so the mutant is not equivalent.