[lyrixx]

A CTRL+C usually reaches Castor itself, which stops. But a process run with the terminal (withTty(), toInteractive()) may put it in raw mode, like docker run -it does: only the process gets the CTRL+C, and it exits with the code 130. When the failures are allowed (withAllowFailure(), exit_code(), toInteractive()), the task then carried on to its next step, so a task running several tools needed one CTRL+C per tool. It showed up in jolicode/docker-starter#453.

Besides, when Castor itself receives the signal, Symfony Console exits with the code 0: castor build && castor deploy went on with the deployment after a CTRL+C.

Changes

A process interrupted on its own stops the task

• A process that exits with 130 while it has the terminal, or that is killed by a SIGINT Castor did not receive, throws a ProcessInterruptedException, whatever allowFailure. It is rendered as a short warning, and Castor exits with 130. Being an exception, the finally blocks of the task still run.
• Without the terminal, Castor receives the CTRL+C itself: the exit code 130 stays a failure like any other, so capture(), pipes and PTY are not affected.
• When SIGINT is trapped with withTrappedSignals(), the task goes on, as documented for the trap.

Castor exits with 128 + the signal number

• When a signal stops Castor, it exits with 128 + the signal number (130 for SIGINT, 143 for SIGTERM, 138 for SIGUSR1...) instead of 0, whatever the signal, as Symfony 8.2 does. InterruptionListener sets this code before the other listeners and the onSignals handlers of the task, which still decide.

Symfony 8.2

symfony/symfony#66950 makes Symfony Console 8.2 exit with 128 + the signal number on its own. Once Castor requires symfony/console ^8.2 (#911), InterruptionListener is redundant and can be removed: a TODO on the class says so. Its test stays, since it checks the behavior, not the listener.

The first part of this PR is still needed with Symfony 8.2. When a process puts the terminal in raw mode, Castor receives no signal at all, so Symfony Console has nothing to react to: the exit code 130 of the process is the only trace of the CTRL+C, and only ProcessRunner can see it. Comments in ProcessRunner say so, to keep this code when the listener goes away.

Trade-offs

• The exit code 130 is a convention, not a proof of a CTRL+C: a process with the terminal that exits with 130 on its own stops the task too. The main case is an interactive shell, which exits with the code of its last command (130 after a CTRL+C at the prompt). Trapping SIGINT lets the task go on after it, the documentation says so.
• parallel(): the jobs never get the terminal, so only the SIGINT case applies, and an interrupted job is reported like a failed one.
• Windows: no TTY and no signals, nothing changes.

Tests

• InterruptionTest runs Castor in a pseudo terminal with script, like ParallelJobsTuiTest. 6 of its 8 tests fail without the change, the 2 others check that the task goes on when it should.
• Checked by hand in a pseudo terminal receiving a real CTRL+C, before and after the change: docker run --rm -it --init alpine sleep 20, a child in raw mode, exit_code(), PTY and pipes, with and without a trap. On a docker-starter task running two container commands, the second one no longer runs, and Castor exits with 130 instead of 0.

Part of #907.