[Access] Prevent script execution for any block height less than the last HCU height

[vishalchangrani]

Problem Definition

What problem is this solving?

The Candence version generally changes during an HCU.
The current implementation of script execution on the Access node allows for script execution on any arbitrary block height starting from the start of the spork. This however means a script executed on an Access node on a past height will execute the script using the current Cadence version which may or may not generate the same result as the script executed on a previous version of Cadence that was running during that past height resulting in inaccurate results.
In the past, this hasn't been an issue since scripts were exclusively executed only on the EN and that too only for block height starting at the HCU height, not before that.

Proposed Solution

What are the proposed solutions to this problem?
The proposed solution is that the access node rejects any script execution request before the last HCU height. In the future, a robust solution such as running multiple FVMs on an AN to support multiple Cadence versions may be explored but for now, to ensure safety, the AN should not attempt to execute scripts on a past block height with a different Cadence version.

Definition of Done

What tests must pass for this issue to be considered solved?
Script execution request for a block height before the last HCU is rejected with an appropriate error message.

Actions Needed Before Submitting

Update ticket status using the following (remove this section once ticket created)

• What workstream does this ticket deal with? Find the appropriate 'S-' label and add that label.
• Is it a specific 'type' of ticket (ex: bug, documentation)? If yes, add that label as well.
• Is this ticket related to an overarching theme (ex: architecture, performance)? If yes, add that label as well.
• Add any/all descriptive characteristic labels needed (ex: Needs Estimation, Needs Test Cases).
• Now we should determine what release this ticket is associated with. If none, leave it blank. If it is associated with a specific release, please add it to the appropriate release.
• If this ticket is associated with a release, we want to assign it a level of importance within that release. These labels follow the standard MoSCoW method rules. We want to look at releases and then the importance of tickets within those specific releases. So the MoSCoW label is ONLY valid when it is taken in conjunction with its release.
• Assign this ticket a priority level (High, Medium, Low) via the appropriate label. These labels control the importance of the ticket within the sprint. For example, all P-High tickets should be worked on first, then P-Medium, then P-Low. This gives us an easy way to identify the order of priority for tickets within a specific sprint.

[peterargue]

This was completed by adding new CLI flags on ANs to specify the start/end heights for script execution (#5283). There's also a follow up issue to integrate with the version beacon (#5040)