Use sync_tolerance_epochs flag to control the proposer prep routines

[jimmygchen]

Issue Addressed

Replace the 2 + 2 == 5 hacks from holesky-rescue and use the existing sync_tolerance_epochs flag to control the proposer prep routines.

[mergify]

This pull request has merge conflicts. Could you please resolve them @jimmygchen? 🙏

[michaelsproul]

Should merge this after (manually) merging this PR:

• Add test flag to override SYNC_TOLERANCE_EPOCHS for range sync testing (#7030) #7045

[michaelsproul]

Merged the original sync tolerance PR to unstable, so this now just contains the new changes.

[jimmygchen]

I haven't really given enough thoughts to this, so this PR changes the following

• PREPARE_PROPOSER_HISTORIC_EPOCHS from 4 to sync_tolerance_epochs
• get_pre_payload_attributes epochs from 2 to sync_tolerance_epochs
• DEFAULT_SYNC_TOLERANCE_EPOCHS for http block production from 8 to sync_tolerance_epochs

sync_tolerance_epochs is now defaulted to 16.

We discussed about DEFAULT_SYNC_TOLERANCE_EPOCHS a while ago but I forgot why it was 8.

@AgeManning had a comment here #6880 (comment)

[michaelsproul]

I think lets change this back to 8.

Now that we have a config flag for it, we have the option of getting people to set it in adverse chain conditions (sparse chain with legitimately very few blocks).

I'm worried that setting it to 16 might have contributed to the plethora of shitty sidechains we saw on Holesky. Whatever value we set here is essentially a bound on "we will build a shitty side chain during sync/stuckness of up to this length". I'd even be tempted to set the default lower, maybe 2 (as Age suggested originally) or 4.

[michaelsproul]

As agreed on the call today, I've lowered the default to 2 in this commit: c7105d1.

In case of a sparse chain and liveness issues, we can advise validators to bump up the sync tolerance temporarily.