client: include parent beacon block root for proposal payload uniquness

[g11tech]

Lighthouse seems to have an optimization where they send a fcU before updating head as well as after updating head. this seems to result into two calls with different parentBeaconBlockRoot (which is the CL head on which proposal is being build)

Since we have not been using parent beacon block root for uniqueness of payload being build, we were returning same payload if to second fcU call (which has an updated parent beacon block root).

This was leading to invalid evaluation of the block hash later in new payload where the correct parent beacon block root supplied by the CL is injected into payload

This PR attempts to fix the same

• TODO : test on the dencun network with lighthouse: successful block production
  

[codecov]

Codecov Report

Merging #2967 (aeca04b) into master (04412bc) will decrease coverage by 0.56%.
The diff coverage is 100.00%.

Additional details and impacted files

Flag	Coverage Δ
block	88.66% <ø> (ø)
blockchain	92.58% <ø> (ø)
client	87.50% <100.00%> (-0.02%)	⬇️
common	98.56% <ø> (ø)
evm	70.43% <ø> (ø)
rlp	∅ <ø> (∅)
statemanager	?
trie	89.92% <ø> (+0.03%)	⬆️
tx	?
util	86.78% <ø> (ø)
vm	79.20% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[holgerd77]

Can't completely judge this change, so just to make sure: the last time I checked the fork monitor from devnet 8 lighthouse was failing for all three EL clients (now everything seems to be in the green again?).

So I was just wondering if it makes sense to adjust to the lighthouse behavior here, or if this would rather be a fix on the lighthouse side? Or is this fix here so generic that we can take anyhow?

[g11tech]

Can't completely judge this change, so just to make sure: the last time I checked the fork monitor from devnet 8 lighthouse was failing for all three EL clients (now everything seems to be in the green again?).

So I was just wondering if it makes sense to adjust to the lighthouse behavior here, or if this would rather be a fix on the lighthouse side? Or is this fix here so generic that we can take anyhow?

generic fix, we should have had parentBeaconBlockRoot in payload uniqueness as CL can freely send a new FcU if its head changes at any moment for the proposal slot

[holgerd77]

Ok, thanks for the clarification, LGTM