feat(l1): enr fork id filtering

[edg-l]

Motivation

Now that we are #5446 from peers, we can filter valid contacts to initiate RLPx connections on lookup.

Closes #5506

[github-actions]

Lines of code report

Total lines added: 87
Total lines removed: 0
Total lines changed: 87

Detailed view

+---------------------------------------------------+-------+------+
| File                                              | Lines | Diff |
+---------------------------------------------------+-------+------+
| ethrex/crates/common/types/fork_id.rs             | 674   | +6   |
+---------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/discv4/peer_table.rs | 1038  | +28  |
+---------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/discv4/server.rs     | 620   | +53  |
+---------------------------------------------------+-------+------+

[ElFantasma]

LGTM

I think there is room for further code refactoring, but there are some pending PRs that may conflict with this one. Let's merge all and take another look at this code afterwards.

[Oppen]

LGTM

I think there is room for further code refactoring, but there are some pending PRs that may conflict with this one. Let's merge all and take another look at this code afterwards.

On those lines, I would suggest:

1. Tracking validated peers separately from unvalidated ones, so we can validate once and forget about it afterwards;
2. Keeping track of invalid peers separately, in a more lightweight way.

Ideally, I think there would be a clear flow like this:

New peer -> validate +-> peer table
                     |
                     +-> bad peers list

[MegaRedHand]

LGTM. I think snap-sync is faster now 🚀 🚀 🚀

[MegaRedHand]

We should probably cache this: #3660 (in another PR)

[ElFantasma]

LGTM
I think there is room for further code refactoring, but there are some pending PRs that may conflict with this one. Let's merge all and take another look at this code afterwards.

On those lines, I would suggest:

1. Tracking validated peers separately from unvalidated ones, so we can validate once and forget about it afterwards;

2. Keeping track of invalid peers separately, in a more lightweight way.

Ideally, I think there would be a clear flow like this:

New peer -> validate +-> peer table
                     |
                     +-> bad peers list

Yeah, I definitely like this approach. Probably several lists with different categories and different update intervals: non-validated-contacts, ping-requested-contacts, enr-requested-contacts, once-connected-contacts, etc... But I think this should be done after #4245, or #4491