test: discover functional tests by scanning the test directory #35725

test/functional/test_runner.py kept a large, manually ordered list of the functional test scripts (BASE_SCRIPTS). Adding a test meant editing that list and guessing a run-time position for it, and the shared, hand-ordered list was a recurring source of merge conflicts.

This replaces the list with get_base_scripts(), which discovers the default tests by scanning the functional test directory.

Result

• Adding a test is just adding the file — a correctly named *.py is picked up automatically; no list entry, no run-time bucket to guess.
• No more merge conflicts on a shared, hand-ordered array.
• Behavior is unchanged: the discovered set of test invocations is identical to the previous list, so which tests run (and how) is the same.

Kept explicit (cannot be derived from the filesystem)

• TEST_PARAMS — tests invoked multiple times with different arguments (e.g. rpc_bind.py --ipv4/--ipv6/--nonloopback).
• EXTENDED_SCRIPTS — extended-only tests.
• LONGEST_BASE_SCRIPT — the longest test, scheduled first so parallel runtime is unaffected.

test/functional/README.md is updated with the simpler instructions for adding a test.

<!--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/35725.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline and AI policy for information on the review process.

If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

Tend to NACK

The script ordering is intentional so that the longest running scripts (note the plural) are scheduled first. Scheduling just the longest running script first may mean that the second longest running test is scheduled as the longest is finishing, potentially doubling the total runtime of the entire test suite. There is no guarantee that all other tests finish before the longest running test finishes.

Adding a test meant editing that list and guessing a run-time position for it

Running the test will tell you the runtime, it's trivially easy to figure out where it should go from there.

Agree with the NACK.

Also, this is ai slop that violates https://github.com/bitcoin/bitcoin/blob/master/doc/AI_POLICY.md

In theory the runtime could be encoded in a special header value inside the test file itself. However, I am not sure if this is worth the churn. Also, it isn't going to solve the problem of which tests are "extended" vs "normal" vs "special" (bench)...