Reduce setup overhead in fuzzing workflow by grouping fuzz targets

[mattsu2020]

The current fuzzing workflow runs each fuzz target as a separate matrix job.

For example, fuzz-run currently defines 19 fuzz targets, and each target runs in its own GitHub Actions job. Each job performs the same setup steps, including checkout, installing cargo-fuzz, setting RUSTC_BOOTSTRAP, and then running a single fuzz target for RUN_FOR=60 seconds.

Proposal

Instead of running every fuzz target as a separate matrix job, we could group related lightweight fuzz targets and run them sequentially within each matrix job.

For example:

strategy:
  matrix:
    group:
      - name: smoke
        targets: "fuzz_test fuzz_date fuzz_expr fuzz_printf fuzz_echo"
      - name: parsers
        targets: "fuzz_parse_glob fuzz_parse_size fuzz_parse_time fuzz_seq_parse_number"
      - name: coreutils
        targets: "fuzz_seq fuzz_sort fuzz_wc fuzz_cut fuzz_split fuzz_tr fuzz_env fuzz_cksum"

Then each job would perform setup once and run multiple fuzz targets:

for target in ${{ matrix.group.targets }}; do
  cargo fuzz run --target $(rustc --print host-tuple) "$target" -- \
    -max_total_time=${{ env.RUN_FOR }} \
    -timeout=${{ env.RUN_FOR }} \
    -detect_leaks=0 \
    -print_final_stats=1
done

Benefits

This should reduce repeated setup overhead by decreasing the number of matrix jobs.

Expected benefits:

fewer repeated checkout operations
fewer repeated cargo-fuzz installations
fewer short-lived GitHub Actions runners
less CI overhead for a workflow where each target only runs for 60 seconds
potentially better workflow stability by reducing excessive parallelism

Trade-offs

The main downside is that failures may be slightly less isolated, because multiple fuzz targets would run in the same job.

However, this can be mitigated by:

keeping logical groups reasonably small
printing clear per-target summaries
uploading stats per group or per target
preserving should_pass / allow-failure behavior inside the loop