Fork choice changes to align with v1.7.0-alpha.1

[StefanBratanov]

PR Description

There is a proposer boost change required in fork choice to align with new specs as per ethereum/consensus-specs#4807 . There is also a refactor to is_parent_strong to cater for Gloas reusing this method, but we can tackle this when we work on the Gloas fork choice changes.

This is prerequisite for all tests to pass in #10261

There is discussion on Discord: https://discordapp.com/channels/595666850260713488/598292067260825641/1458453736417394791

Fixed Issue(s)

N/A

Documentation

• I thought about documentation and added the doc-change-required label to this PR if updates are required.

Changelog

• I thought about adding a changelog entry, and added one if I deemed necessary.

---

Note

Aligns fork choice with the v1.7.0-alpha.1 consensus spec and adjusts reference tests.

• Updates proposer boost handling: replace shouldApplyProposerBoost with shouldUpdateProposerBoostRoot to boost only when the block is timely (via recentChainData.isBlockLate), is the first in slot, and the proposer matches the canonical chain’s proposer; processes head state as needed to determine proposer index
• Removes time-into-slot calculation and related import; adds handling for slot/epoch processing exceptions during head state progression
• Calls to update fork choice now use the new proposer-boost flag; retains reorg handling via processHead() when appropriate
• Adds RecentChainData.isBlockLate(Bytes32) to surface lateness from LateBlockReorgLogic
• Bumps consensus-spec reference tests in build.gradle to v1.7.0-alpha.1

^{Written by Cursor Bugbot for commit 82a4ef4. This will update automatically on new commits. Configure here.}

[gfukushima]

it seems to me that this is the logic of update_proposer_boost_root not the logic of should_apply_proposer_boost

[rolfyone]

+1 this doesnt look similar to should_apply_proposer_boost, agree... also if this code does land somewhere we'd want finals etc... i'd have expected to fail the build...
isTimely is tied up in the LateBlockReorgLogic class (isBlockTimely), I think the spec references thing referencing forkChoice is a bit of a lie - not part of this pr, but yeh its going to be fun altering update_proposer_boost_root potentially, we might need to pull some things apart a little

in older specs we had should_override_forkchoice_update (found in 1.6.0), I'm not sure, but it seems like maybe that's what's been broken down to all this... that's the main logic in LateBlockReorgLogic, maybe this helps understand where all the logic is coming from, not sure...

hopefully some of that helps?

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

[cursor]

Unhandled exception when head state exceeds current slot

Low Severity

When headState.getSlot() is greater than currentSlot (possible during system clock regression), the code skips slot processing but still calls spec.getBeaconProposerIndex(headState, currentSlot). If these slots span different epochs, this call throws an IllegalArgumentException from the epoch validation check. This exception is not caught by the existing catch block (which only handles SlotProcessingException and EpochProcessingException), causing an unhandled exception that fails the block import. The old implementation would gracefully return false in slot mismatch scenarios.