Eth: BlockRef

[axelKingsley]

Adds an alias for L1BlockRef called BlockRef and uses it throughout the Supervisor.

This is because the supervisor was dealing with a mix of L1 and L2 block references. Even though logically most references are L2, we only need as much data as the L1 reference had, so they were being used interchangeably. This way everything is using the same type.

[semgrep-app]

Semgrep found 8 golang_fmt_errorf_no_params findings:

• op-e2e/external_geth/main.go
  • L35 - Triage
  • L50 - Triage
  • L53 - Triage
  • L70 - Triage
  • L106 - Triage
  • L137 - Triage
  • L171 - Triage
  • L175 - Triage

No fmt.Errorf invocations without fmt arguments allowed

_{Ignore this finding from golang_fmt_errorf_no_params.}

Semgrep found 3 dangerous-exec-command findings:

• op-e2e/system/e2esys/external.go
  • L111 - Triage
• op-e2e/external_geth/main.go
  • L112-117 - Triage
  • L139-161 - Triage

Detected non-static command inside Command. Audit the input to 'exec.Command'. If unverified user data can reach this call site, this is a code injection vulnerability. A malicious actor can inject a malicious script to execute arbitrary code.

_{Ignore this finding from dangerous-exec-command.}

[geoknee]

I would suggest describing BlockRef as the "the common properties of L1 and L2 blocks", to avoid any ambiguity where we might expect it to "work" as an L2 block in all cases.

We could also consider embedding BlockRef into L2BlockRef, which could reduce duplication across a lot of the methods. But, this may result in some yak shaving (we would need to update hundreds of cases where we construct a literal L2BlockRef).