fix(fuzz): Avoid OOB when in_no_dynamic mode

[aakoshh]

Description

Problem*

Resolves #9853

Summary*

Changes the AST fuzzer to avoid generating code that might overflow an array index when we are in an ACIR function and the array contains references, ie. when we generally must avoid dynamic input.

Additional Context

The ticket contains SSA when an index overflows:

    v11 = unchecked_mul u32 2147483648, u32 2
    v12 = array_get v9, index v11 -> &mut Field
    v14 = unchecked_add v11, u32 1
    v15 = array_get v9, index v14 -> u1

and when it doesn't:

    v11 = array_get v9, index u32 4294967294 -> &mut Field
    v13 = array_get v9, index u32 4294967295 -> u1

Both of them are out of bounds, but the first one doesn't compile, as it's considered "dynamic" by verify_no_dynamic_indices_to_references, while the second only causes a runtime failure.

Initially I went down the route of modifying verify_no_dynamic_indices_to_references to look at the index and if it's coming from an instruction which uses only constants, then consider it a constant. However, this just shifted the failure back to where it was before this SSA pass was introduced:

error: Could not resolve some references to the array. All references must be resolved at compile time
  ┌─ src/main.nr:2:50
  │
2 │     let mut e: [(&mut Field, bool); 1] = [((&mut -1), false)];
  │                                                  --
  │
  = Call stack:
    1. src/main.nr:2:50

That is returned if, during ACIR gen, we encounter an allocate. Given that this is the last pass in the pipeline, there is nothing we can do about it: since mem2reg failed to handle the overflowing index, it could not eliminate the references. We could call codegen_access_check to get a constraint failure, like we do in Brillig, but it's not worth it for this edge case.

Since this is only a result of not avoiding obviously overflowing indexes in fuzzing, to avoid the discrepancy between Brillig and ACIR, we just stop generating such code.

It did bring out another bug though: when the array does not contain references, we still end up with the unchecked_add left in the SSA, but this time it correctly results in an OOB at runtime. When I checked what happens with the index if it overflows from u32::MAX to 0, it turned out that ACIR does not wrap around, but the SSA interpreter does, so for the latter andoverflow can be turned back into a success (see #9856). I'm not sure if this is the intended behaviour in ACIR!

Documentation*

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist*

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Execution Time'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: e0f5090	Previous: 639b1f6	Ratio
rollup-root	0.005 s	0.004 s	1.25

This comment was automatically generated by workflow using github-action-benchmark.

CC: @TomAFrench

[github-actions]

⚠️ Performance Alert ⚠️

Possible performance regression was detected for benchmark 'Test Suite Duration'.
Benchmark result of this commit is worse than the previous benchmark result exceeding threshold 1.20.

Benchmark suite	Current: e0f5090	Previous: 639b1f6	Ratio
test_report_noir-lang_sha512_	15 s	12 s	1.25

This comment was automatically generated by workflow using github-action-benchmark.

CC: @TomAFrench