ux: allow interrupting in-progress push operation in dialog

[sdpfigueiredo]

Resolve #2603

Problem

When the remote server is unreachable (e.g. corporate VPN down), the Push Changes to Remote dialog blocks for minutes on the hung git push process with no way to interrupt it — the dialog is not closable while the operation is in progress.

Solution

Add an opt-in cancellation mechanism for popups and wire it up for the Push dialog:

• Popup base class gains CanCancel (default false) and Cancel(), and Cleanup() becomes virtual.
• Push overrides CanCancel => true and Cancel() → cancels a CancellationTokenSource whose token is passed to the push command via the existing .WithCancellation(token) extension. Command.ExecAsync() already kills the git process tree on cancellation, and returns true when cancelled — so the dialog closes itself once the operation is interrupted.
• PopupRunningStatus shows a CANCEL button next to the running indicator, visible only when the popup opts in (CanCancel).
• LauncherPage.CancelPopup() now forwards to popup.Cancel() when a cancellable popup is in progress, so ESC and mask-click also interrupt the running push.

Behavior

1. Push is running (hung on unreachable remote)
2. User clicks CANCEL (or presses ESC / clicks outside)
3. git push process tree is killed
4. Dialog closes immediately

Notes

• Changes are opt-in: no other dialog is affected (button only appears for popups with CanCancel == true).
• PushTag / PushRevision follow the same pattern and can opt in later if desired.

Tested: dotnet build clean (0 warnings / 0 errors). Windows win-x64 NativeAOT publish successful.

Screenshot

[love-linger]

Not planned yet. See #1012

[love-linger]

Currently, we use Process.Kill(true) to force terminating a git sub-process. It's unsafe and only used for read-only git commands (such as git diff).

If you are running SourceGit on Windows, I can push a branch that can gracefully ternimate git process.

[love-linger]

I've pushed my implementation (only supported Windows)

[Mingun]

Sending Ctrl+C to git process will not interrupt git operation correctly?

[love-linger]

Sending Ctrl+C to git process will not interrupt git operation correctly?

Yes. I just do this on Windows. For Linux/macOS, you can not gracefully terminate a process tree with signal SIGINT/SIGTERM (Process.Start does not spawn process in a seperate session/group)

[Mingun]

(Process.Start does not spawn process in a seperate session/group)

Does it matter? I was sure, that the git process is responsible to correctly handle Ctrl+C and if it allow that to do, that should be safe.

[love-linger]

As I said - Sending Ctrl+C works fine on Windows. On Linux/macOS, there are some issues in sending signal SIGINT/SIGTERM. See dotnet/runtime#44944

[aikawayataro]

(Process.Start does not spawn process in a seperate session/group)

Does it matter? I was sure, that the git process is responsible to correctly handle Ctrl+C and if it allow that to do, that should be safe.

The way dotnet handles child processes makes it hard to reliably wait for completion. It is safe to kill git processes with SIGINT and SIGTERM, but because signal is not sent to the children, they will become background "zombie" processes for a while. From my point of view, this behavior is totally fine, main git process exited and any filesystem IO is cleanly closed, the live children are harmless network fetch processes.
I come up with somewhat elegant workaround here: #1012 (comment) the rest of discussion will tell you why it was not merged.