Ensure dotnet test for MTP cancellation is handled correctly

[Youssef1313]

should we pass cancellationToken to this? it seems that once we start the process we do not cancel here?

Originally posted by @drognanar in #50727 (comment)

[Youssef1313]

I think today's behavior is that Ctrl+C is captured by individual test apps (the child processes) and then it's up to the individual test apps to react on cancellation.

That's probably reasonable. The alternative is that we kill child processes immediately and don't have to wait for them to cancel.

Advantages of leaving it for the child processes to cancel and terminate themselves is they have the chance to do any cleanup, if needed.

Advantages of killing is that we respond immediately to user's Ctrl+C request.

If we want to combine both, we can do one or both of:

1. After Ctrl+C, we give the child processes some time to cancel themselves, and kill afterwards. But such time is going to be "arbitrary", which I don't like.
2. We could interpret a second Ctrl+C request as "kill immediately". So, on first Ctrl+C we leave the test apps to cancel themselves. But on second one we kill.

cc @baronfel if you have any thoughts/preferences.

[baronfel]

There are existing concepts for 'soft termination' vs 'hard termination' in POSIX signals:

• SIGTERM/SIGQUIT is the 'soft' cancellation - processes usually have some defined, small window of time to cleanup and terminate. We can listen to and respond to this signal in modern .NET
• SIGKILL is the 'hard' cancellation - a process is forcibly terminated. We have no way to respond to this in .NET.

What I'd suggest is that the top-level process handle SIGTERM/SIGQUIT by sending the same signal to any child processes, waiting some defined/configurable amount of time, and then forcibly stopping any that remain.

There are some examples in the runtime of working with Signals, like in the SystemdLifetime.