Fix _handle_signals TypeError when SIGTERM is delivered to a forked child

[dwoz]

What does this PR do?

Fixes a decade-old bug in salt.utils.process.ProcessManager._handle_signals:

return signal.default_int_handler(signal.SIGTERM)(*args)

signal.default_int_handler requires (signum, frame). The buggy line calls it with a single positional arg, catches the resulting TypeError nowhere, and kills the receiving process with an unhandled exception instead of the intended clean shutdown.

Traceback observed in the wild on Salt 3008.1 when SIGTERM was delivered to the master:

File "salt/utils/process.py", line 817, in _handle_signals
    return signal.default_int_handler(signal.SIGTERM)(*args)
TypeError: default_int_handler expected 2 arguments, got 1

MasterPubServerChannel._publish_daemon crashed and ProcessManager did NOT respawn it.

Why is the elif arm reachable?

signal.getsignal(SIGTERM) returns signal.Handlers.SIG_DFL (an enum, not callable and not None) in a fresh interpreter, so the first two arms of the if fall through to the buggy one.

Fix

Pass through the received (signum, frame) tuple. default_int_handler raises KeyboardInterrupt regardless of signum, matching the original intent.

Test

tests/pytests/functional/utils/test_process.py::test_handle_signals_default_int_handler_typeerror forces the child branch, sets _sigterm_handler to SIG_DFL, and asserts _handle_signals raises KeyboardInterrupt (was TypeError before this patch).

Backporting: bug also present on 3007.x, 3008.x, master; will forward-port via merge-forwards.