perf(p2p): randomize contact selection for RLPx connection initiation

[azteca1998]

Summary

• Randomize contact selection in get_contact_to_initiate to avoid sequential bucket traversal bias

Builds on #6497 (peer pruning fix).

Problem

After #6458 introduced the Kademlia k-bucket routing table, snap sync times regressed (~50-75% slower across hoodi, sepolia, mainnet). Part of the slowdown comes from do_get_contact_to_initiate iterating buckets sequentially from 0→255. Due to XOR distance distribution, ~87% of contacts cluster in buckets 253-255, while buckets 0-200 are nearly empty. Sequential traversal wastes connection attempts on sparse low-numbered buckets before reaching the dense high-numbered ones where most peers live.

Changes

Replace the sequential for bucket in &self.buckets loop with random selection from all eligible contacts across all buckets (main + replacements). This follows the same pattern already used by get_contact_for_lookup and get_contact_for_enr_lookup.

Test plan

• All 33 p2p unit tests pass
• Run daily snapsync test and compare sync times against baseline

[github-actions]

Lines of code report

Total lines added: 29
Total lines removed: 0
Total lines changed: 29

Detailed view

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

[azteca1998]

Superseded by #6511 (Kademlia v2) — randomized selection replaced by O(1) random index probe.