feat(l1): request updated ENR when PONG enr_seq differs from cached

[ElFantasma]

Motivation

Per the discv5 spec, when receiving a PONG with an ENR sequence number different from our
cached version, we should request the updated ENR using FINDNODE with distance 0. This
ensures we have up-to-date ENRs for peers (IP changes, capability updates, etc.).

Description

• Implements ENR update request in handle_pong when PONG's enr_seq differs from cached
  value
• Sends FINDNODE with distance 0 to request the peer's current ENR
• Adds unit test test_enr_update_request_on_pong verifying:
  • PONG with matching enr_seq does NOT trigger FINDNODE
  • PONG with different enr_seq DOES trigger FINDNODE

Closes #5850

[github-actions]

Kimi AI Code Review

This PR aims to improve the handling of ENR updates in the DiscoveryServer by requesting updated ENRs when a PONG message has a different enr_seq than the cached version. Here's a detailed review:

Code Correctness and Potential Bugs

1. Line 473-493: The code correctly checks if the enr_seq from the PONG message differs from the cached sequence number. If they differ, it requests an updated ENR by sending a FINDNODE message with a distance of 0. This logic seems correct.

2. Line 882-898: The test case test_enr_update_request_on_pong is added to verify the new functionality. The test creates a local and remote node, adds the remote node to the peer table, and then tests the behavior of the handle_pong method with PONG messages having different enr_seq values. The test appears to be comprehensive and correctly checks the expected behavior.

Security Vulnerabilities

1. Line 473-493: The code does not introduce any obvious security vulnerabilities. It correctly handles the case where the enr_seq differs, which is important for maintaining an up-to-date view of the network.

Performance Implications

1. Line 473-493: Requesting updated ENRs when the sequence number differs could lead to additional network traffic. However, this is necessary to ensure the local node has the most recent information about remote nodes. The performance impact should be minimal as long as the frequency of ENR updates is reasonable.

Rust Best Practices and Idiomatic Patterns

1. Line 473-493: The code follows Rust best practices by using await? for asynchronous operations and handling potential errors. The use of trace! for logging is also appropriate.

Memory Safety and Proper Error Handling

1. Line 473-493: The code correctly handles potential errors by using await?. It also checks for None values before accessing fields, which prevents panics due to unwrapping None.

Code Readability and Maintainability

1. Line 473-493: The code is well-structured and easy to understand. The comments explaining the logic are helpful.

2. Line 882-898: The test case is well-named and clearly describes its purpose. The test setup is detailed and ensures the test covers the intended scenario.

Ethereum-specific Considerations

1. Line 473-493: The code does not directly interact with EVM opcodes, gas accounting, consensus rules, or RLP encoding/decoding. However, maintaining accurate ENR information is crucial for the overall health of the Ethereum network, as it affects node discovery and connectivity.

Overall, this PR looks good. It introduces a necessary improvement to handle ENR updates correctly and includes a comprehensive test case to verify the new functionality. The code follows Rust best practices and is well-structured for readability and maintainability. I approve this PR with no changes requested.

---

Automated review by Kimi (Moonshot AI)