Use should_build_on_full for bid parent block hash (#5310)

Author: nflaig

specs/gloas/validator.md

@@ -182,6 +182,9 @@ def get_proposer_preferences_signature(
 
 #### Constructing the `BeaconBlockBody`
 
+Let `head = get_head(store)` be the parent block the proposer is building on,
+from which `state` was derived.
+
 ##### Signed execution payload bid
 
 To obtain `signed_execution_payload_bid`, a block proposer building a block on
@@ -202,7 +205,7 @@ top of a `state` MUST take the following actions in order to construct the
   - The `bid.slot` is for the proposal block slot.
   - The `bid.parent_block_hash` equals
     `state.latest_execution_payload_bid.block_hash` if
-    `should_extend_payload(store, block.parent_root)` is true, otherwise
+    `should_build_on_full(store, head)` is true, otherwise
     `state.latest_execution_payload_bid.parent_block_hash`.
   - The `bid.parent_block_root` equals the current block's `parent_root`.
 - Select one bid and set
@@ -232,8 +235,7 @@ construct the `payload_attestations` field in `BeaconBlockBody`:
 ##### Parent execution requests
 
 The `parent_execution_requests` field contains the execution requests from the
-parent's execution payload. Let `head = get_head(store)`. The proposer
-constructs this field as follows:
+parent's execution payload. The proposer constructs this field as follows:
 
 - If the parent block is pre-Gloas (first Gloas block), set
   `parent_execution_requests` to an empty `ExecutionRequests()`.
@@ -245,14 +247,11 @@ constructs this field as follows:
 
 ##### ExecutionPayload
 
-*Note*: `prepare_execution_payload` is modified in Gloas to take `store` and
-`head` as additional parameters. `head` is the return value of `get_head(store)`
-and must correspond to the parent that `state` was derived from. It consults
-`should_build_on_full(store, head)` to decide whether to build on the parent's
-full payload or its empty variant, selecting both the withdrawals source and the
-execution head for the new payload. When building on a full parent,
-`apply_parent_execution_payload` is called so that withdrawals are computed
-against the post-processing state.
+*Note*: `prepare_execution_payload` is modified to build on the parent's full
+payload or its empty variant, as decided by `should_build_on_full(store, head)`,
+which determines the withdrawals source and the execution head for the new
+payload. When building on a full parent, `apply_parent_execution_payload` is
+called so that withdrawals are computed against the post-processing state.
 
 ```python
 def prepare_execution_payload(