Backport overall status timeout budget to release-7.4

[hxu]

This backports the original overall-budget commit and the client-phase correction and tests from #13759 to release-7.4. It is the release-7.4 counterpart to the release-7.3 backport, #13749.

The original change gave controller discovery and the cluster status RPC one shared deadline, but the earlier client-side coordinator quorum probe retained its fixed two-second timeout. That gap allowed STATUS_TIMEOUT=0.2 to take two seconds during a coordinator outage. This backport carries the deadline through all three phases and includes separate regression coverage for the client probe and cluster RPC budget.

release-7.4 still uses actor-based StatusClient.actor.cpp and supports filtered status requests, so the semantic cherry-pick keeps the actor state and statusField API while preserving the original author and source-commit metadata.

Summary of PRs:

1. Bound status fetch latency to overall timeout budget #13210 - this is the original PR that threaded through the status timeout
2. Include client probe in overall status timeout budget #13759 - a new PR that additionally threads the timeout budget to the client and coordinator fetcher, plus adds the test

Then:

1. Backport overall status timeout budget to release-7.3 #13749 - backports the two PRs above to 7.3
2. Backport overall status timeout budget to release-7.4 #13760 (this PR) - backports the two PRs above to 7.4

Testing:

• Debug fdbserver build: passed
• fdbserver -r unittests -f /fdbclient/status/: 2 passed

Code-Reviewer Section

The general pull request guidelines can be found here.

Please check each of the following things and check all boxes before accepting a PR.

• The PR has a description, explaining both the problem and the solution.
• The description mentions which forms of testing were done and the testing seems reasonable.
• Every function/class/actor that was touched is reasonably well documented.

For Release-Branches

• This change/bugfix is a cherry-pick from the next younger branch (younger release-branch or main if this is the youngest branch)
• There is a good reason why this PR needs to go into a release branch and this reason is documented (either in the description above or in a linked GitHub issue)

[foundationdb-ci]

Result of foundationdb-pr-macos-m1 on macOS 14.x

• Commit ID: 3d82058
• Duration 0:35:56
• Result: ✅ SUCCEEDED
• Error: N/A
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)

[foundationdb-ci]

Result of foundationdb-pr-clang on Linux RHEL 9

• Commit ID: 3d82058
• Duration 0:42:06
• Result: ✅ SUCCEEDED
• Error: N/A
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)

[foundationdb-ci]

Result of foundationdb-pr-clang-arm on Linux RHEL 9

• Commit ID: 3d82058
• Duration 0:47:31
• Result: ✅ SUCCEEDED
• Error: N/A
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)

[foundationdb-ci]

Result of foundationdb-pr-macos on macOS 14.x

• Commit ID: 3d82058
• Duration 0:53:42
• Result: ✅ SUCCEEDED
• Error: N/A
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)

[foundationdb-ci]

Result of foundationdb-pr on Linux RHEL 9

• Commit ID: 3d82058
• Duration 0:56:07
• Result: ❌ FAILED
• Error: Error while executing command: if python3 -m joshua.joshua list --stopped | grep ${ENSEMBLE_ID} | grep -q 'pass=10[0-9][0-9][0-9]'; then echo PASS; else echo FAIL && exit 1; fi. Reason: exit status 1
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)

[foundationdb-ci]

Result of foundationdb-pr-cluster-tests on Linux RHEL 9

• Commit ID: 3d82058
• Duration 1:28:19
• Result: ✅ SUCCEEDED
• Error: N/A
• Build Log terminal output (available for 30 days)
• Build Workspace zip file of the working directory (available for 30 days)
• Cluster Test Logs zip file of the test logs (available for 30 days)