perf(l1): optimize get closest nodes

[edg-l]

According to profiling, the get_closest_nodes is mainly bound by iterating the contacts btreemap.

Replaced the contacts btreemap with indexmap. Also replaced the peers one since it also beneffits from this.

Comparing profiling info, it goes from 31% of time taken to 3%.

Hoodi synced in 7mins 32seconds more or less

Reasoning:

Btreemap has fast lookup and slow iteration.
indexmap has fastish lookup and vec-like iteration

IndexMap derives a couple of performance facts directly from how it is constructed, 
which is roughly:

    A raw hash table of key-value indices, and a vector of key-value pairs.

    Iteration is very fast since it is on the dense key-values.

    Removal is fast since it moves memory areas only in the table, 
and uses a single swap in the vector.

    Lookup is fast-ish because the initial 7-bit hash lookup uses SIMD, and indices are 
densely stored. Lookup also is slow-ish since the actual key-value pairs are stored separately. (Visible when cpu caches size is limiting.)

introduces a new dep: https://crates.io/crates/indexmap ( 662,138,228 downloads )

[github-actions]

Lines of code report

Total lines added: 1
Total lines removed: 0
Total lines changed: 1

Detailed view

+---------------------------------------------------+-------+------+
| File                                              | Lines | Diff |
+---------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/discv4/peer_table.rs | 915   | +1   |
+---------------------------------------------------+-------+------+

[github-actions]

Benchmark Block Execution Results Comparison Against Main

Command	Mean [s]	Min [s]	Max [s]	Relative
base	87.182 ± 0.422	86.533	87.853	1.00
head	87.681 ± 0.272	87.302	88.215	1.01 ± 0.01

[MegaRedHand]

Does indexmap have something like Vec::retain ? We could replace this loop with that

[edg-l]

i would prefer to look at this in another pr/change

[ElFantasma]

Whoa, nice improvement!