Bound post-kill WaitForExit to prevent scenario-test hangs

[nagilson]

Problem

The scenario-test harness intermittently hangs a test leg until the pipeline task timeout (observed as a 4h hang producing no .trx). It shows up most on the newest distro image in the source-build offline validation matrix — SB_Fedora43_Offline_PreviousSourceBuiltSdk_Validation_x64 — and a retry sometimes passes, so it's a race, not a deterministic failure. Tracked in dotnet/source-build#5624.

Root cause

Every process-teardown path kills a long-running process (e.g. dotnet run on a web template) with Kill(true) and then calls the parameterless WaitForExit():

process.Kill(true);
process.WaitForExit();   // blocks until stdout/stderr pipes hit EOF

Because stdout/stderr are redirected and read asynchronously (BeginOutputReadLine), WaitForExit() waits for the async readers to reach EOF on the pipes, not merely for the process to exit. dotnet run launches the app as a child/grandchild that inherits those pipe write handles. Kill(true) signals the process tree known at that instant, but if a descendant survives the kill for a moment (tree-walk race / reparent to pid 1), it keeps the write end open, EOF never arrives, and WaitForExit() blocks forever. Newer Fedora 43 (kernel + systemd + cgroup v2 reaping differences) makes the lingering-child race most likely, and the offline PreviousSourceBuiltSdk legs hit the timeout→kill path most often.

Fix

Bound every post-kill wait with a grace timeout (ExecuteHelper.KillGraceMilliseconds = 30_000) so the run fails fast instead of hanging. On the already-failing/timeout path, accepting possibly-truncated output is fine. Three sites:

• Microsoft.DotNet.ScenarioTests.Common/ExecuteHelper.cs — ExecuteProcess
• Microsoft.DotNet.ScenarioTests.SdkTemplateTests/DotNetSdkHelper.cs — ExecuteRunWeb and ExecuteRunUIApp

Minimal, behavior-preserving for the healthy path; only the pathological "won't die / pipe held open" case changes (from infinite hang to fast failure). Built locally with build.cmd (0 warnings, 0 errors).

Note: the VMR carries a sibling copy at test/TestUtilities/ExecuteHelper.cs (dotnet/dotnet) with the identical pattern; that one should get the same bound separately.

Investigation

Full analysis and signals: dotnet/source-build#5624

cc @akoeplinger @ViktorHofer — you're the most active maintainers here; would appreciate a review.

[nagilson]

@ViktorHofer @mthalman Thanks for your review, I don't have permission to merge this so would appreciate a merge now.

[mthalman]

/backport to release/10.0