perf(p2p): add flat connection pool decoupled from Kademlia routing table

[azteca1998]

Summary

• Add a separate flat connection pool (50K capacity) for RLPx connection initiation, decoupled from the k-bucket routing table
• Randomize contact selection from the pool to avoid bucket traversal bias

Builds on #6497 (peer pruning fix). Alternative/complementary to #6503 (randomization-only approach).

Problem

The Kademlia k-bucket routing table (#6458) limits stored contacts to 256 × 16 = 4,096 by design. The old flat IndexMap held up to 100K. This 25x reduction in candidate pool size caused snap sync regressions of 39-75% across all networks because:

1. Fewer candidates for connection initiation → slower ramp to TARGET_PEERS (100)
2. Faster exhaustion of candidates → more frequent retries of failed contacts
3. XOR distance distribution means ~87% of contacts cluster in buckets 253-255, but each bucket only holds 16

Changing k-bucket sizes would break Kademlia protocol semantics, so the routing table structure can't be modified.

Approach

Decouple "routing table" from "connection candidate pool":

• K-buckets (unchanged): used for all Kademlia protocol operations (get_closest_nodes, get_nodes_at_distances, get_contact_for_lookup, etc.)
• Connection pool (new): flat IndexMap<H256, Node> capped at 50K, used exclusively by get_contact_to_initiate for RLPx connection initiation

All discovered contacts are inserted into both structures. The connection pool is cleaned during prune() and uses k-bucket state for filtering when available (unwanted, fork ID validity). Contacts only in the pool (not in k-buckets) are assumed eligible — the RLPx handshake rejects incompatible peers.

Changes

• Add connection_pool: IndexMap<H256, Node> field to PeerTableServer
• Insert into pool on every discovery path (new_contacts, new_contact_records, insert_if_new)
• Rewrite do_get_contact_to_initiate to draw from pool with random selection
• Clean pool entries during prune() when contacts are discarded

Test plan

• All 33 p2p unit tests pass
• Run daily snapsync test and compare sync times against baseline (pre-kademlia) and perf(p2p): randomize contact selection for RLPx connection initiation #6503 (randomization-only)
• Monitor peer count during sync — should show higher diversity than k-bucket-only approach

[github-actions]

Lines of code report

Total lines added: 53
Total lines removed: 0
Total lines changed: 53

Detailed view

+------------------------------------------------+-------+------+
| File                                           | Lines | Diff |
+------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/peer_handler.rs   | 555   | +4   |
+------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/peer_table.rs     | 1277  | +48  |
+------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/sync/snap_sync.rs | 1020  | +1   |
+------------------------------------------------+-------+------+

[github-actions]

Benchmark Block Execution Results Comparison Against Main

Command	Mean [s]	Min [s]	Max [s]	Relative
base	62.433 ± 0.163	62.234	62.719	1.00
head	62.482 ± 0.189	62.260	62.948	1.00 ± 0.00

[azteca1998]

Superseded by #6511 (Kademlia v2) which includes the connection pool + all performance fixes.