fuzz: Bound package eval tx fanout #35318

Fixes #35207.

The tx_package_eval fuzz target intentionally creates multi-transaction packages, including packages over the package-count limit. However, it does not need each generated transaction's input and output counts to scale with the reusable mempool outpoint set. After the ancestor and descendant size limits were removed from mempool limits, that can make some generated inputs spend a large amount of time in set churn rather than package evaluation.

This bounds the per-transaction input/output fanout generated by the harness while keeping the existing 1-to-26 transaction package range. The final package transaction still spends all in-package outputs, so the target continues to exercise package evaluation paths and the package-count boundary.

Testing:

cmake --build build_fuzz_nosan --target fuzz -j2
cmake --build build_fuzz --target fuzz -j2
ASAN_OPTIONS=detect_leaks=0 FUZZ=tx_package_eval build_fuzz/bin/fuzz -rss_limit_mb=2560 -timeout=60 -max_total_time=300 /tmp/qa-assets/fuzz_corpora/tx_package_eval
FUZZ=tx_package_eval build_fuzz_nosan/bin/fuzz -rss_limit_mb=2560 -timeout=60 -max_total_time=180 /tmp/qa-assets/fuzz_corpora/tx_package_eval

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35318.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process. A summary of reviews will appear here.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #33966 (refactor: disentangle miner startup defaults from runtime options by Sjors)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

Timeouts are worthwhile fixing, but reviewing this is not going to be a priority for me, because it ranks quite low on the long list of things that I think are worthwhile.

The testing steps listed don't do much to verify that this issue has been resolved. A longer fuzzing campaign to confirm timeouts are not still present, and coverage report comparisons (before/after) would be needed.

Right, also the magic numbers should be explained, so that it is clear the target can still reach all relevant coverage.

Updated the patch to explain the fanout bounds next to the constants. The bound is per non-final transaction; with the existing 1-to-26 transaction package range, the final transaction can still spend up to 25 * 8 in-package outputs, so the target still exercises multi-transaction package topology and the package-count boundary without letting each generated transaction scale with the reusable mempool outpoint set.

I also ran longer corpus campaigns against the public qa-assets corpus:

cmake --build build_fuzz_nosan --target fuzz -j2
cmake --build build_fuzz --target fuzz -j2
ASAN_OPTIONS=detect_leaks=0 FUZZ=tx_package_eval build_fuzz/bin/fuzz -rss_limit_mb=2560 -timeout=60 -max_total_time=300 /tmp/qa-assets/fuzz_corpora/tx_package_eval
FUZZ=tx_package_eval build_fuzz_nosan/bin/fuzz -rss_limit_mb=2560 -timeout=60 -max_total_time=180 /tmp/qa-assets/fuzz_corpora/tx_package_eval

The ASan run completed 2513 runs in 301 seconds with no timeout/crash. The non-sanitized run completed 14141 runs in 181 seconds with no timeout/crash. After rebasing onto current master, I rebuilt both fuzz targets successfully.

I have not produced a full before/after coverage report locally.