feat(l1): handle non-canonical headers by hash in GetBlockHeaders

[MegaRedHand]

Motivation

We're currently returning empty header responses when we receive a GetBlockHeaders request specifying the start with the block's hash, and the hash isn't part of our canonical view of the chain.

Description

This PR adds support for this case by simply looking for the starting block in the DB and returning it. This stays simple enough and, though suboptimal, should make the simple case of a peer asking for a sidechain to work.

It could be further extended by looking for the block's parent through the parent hash, which should allow us to support cases where reverse is true.

[Copilot]

Pull Request Overview

This PR enhances the GetBlockHeaders functionality to handle requests that specify a starting block by hash when the hash is not in the canonical chain. Previously, such requests returned empty responses, but now they can return the block header if found in the database.

• Refactors the header fetching logic to preserve hash-based lookups when the block isn't in the canonical chain
• Adds support for retrieving block headers by hash from storage
• Implements proper error handling and logging for database access issues

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[github-actions]

Lines of code report

Total lines added: 24
Total lines removed: 0
Total lines changed: 24

Detailed view

+-------------------------------------------------+-------+------+
| File                                            | Lines | Diff |
+-------------------------------------------------+-------+------+
| ethrex/crates/networking/p2p/rlpx/eth/blocks.rs | 338   | +24  |
+-------------------------------------------------+-------+------+

[mpaulucci]

According to https://github.com/ethereum/devp2p/blob/master/caps/eth.md#getblockheaders-0x03 , even when fetching by hash, it should be part of the canonical chain, so maybe we should adapt the code/comments to that?

[MegaRedHand]

I didn't catch that part of the spec before, but Geth apparently services the request even if the hash is not part of the canonical chain:

https://github.com/ethereum/go-ethereum/blob/7e7925460507db9988088223ecd069af507815d6/eth/protocols/eth/handlers.go#L193

We can keep the logic as it was before, since it already supports returning headers in the canonical chain. I think we should add this, however, since the current behavior could cause problems in our syncing algorithm when handling reorgs in an ethrex-only network.

[MegaRedHand]

b8e2005