Interop: Integrate for new input flow

[axelKingsley]

Builds from: #12204
The fixes so far are:

• New APIs not linked to Server ✅
• Supervisor client was casting the chainID inappropriately ✅
• Supervisor Backend had no implementation for
  • Update Local Unsafe ✅
  • Update Local Safe ✅
  • Update Finaliazed L1 ✅
  • Unsafe View ✅
  • Safe View ✅
  • Finalized
• ChainsDB had no implementation for
  • Update Local Unsafe✅
  • Update Local Safe✅
  • Update Finalized✅
  • Unsafe View✅
  • Safe View✅
  • Finalized

Currently Tracking Down:

Incomplete State when calling HeadPointer()

When attempting to get HeadPointers from the State, I see

failed to check unsafe-level view: failed to share unsafe block view View(local: 0x88b33dd0b4f00107715a99f2f5340f17f6a7214f45611248822367485a90f90e:8, cross: 0xf5afaa7bd6b330fce0251d91c2eb58c94ac421e45d6561a676d2e7b9a04886c7:6) (chain 900200): failed to get unsafe view: cannot provide head pointer while state is incomplete"

To address this, I added logging to the error which shows which flags are still needed.

(note: needs is a set of bitmap flags which signal to the iterator state that it is expecting to infer some data

In all cases, it was reported that the CanonicalHash flag was still set.

Investigating CanonicalHash flag, I see it gets triggered for the iterator state from four locations:

• During infer after a checkpoint
• During DB Initialization
• When a new iterator is created with NewIteratorAt
• During ProcessEntry

To be honest, I don’t really understand why a canonical hash should be flagged during some of these. I’m spending a little time to try to understand better.

In the meantime, to timebox: I figured that if there was a needed canonical hash in the iterator state, it wasn’t so bad and so for now I’m just jumping over that check.

it’s not clear that jumping over this check is the right thing to do, but given that the cause seems to be unnecessary canonicalHash needs, ignoring that error seems to be safe in the moment.

[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.}