hping had better reset signal mask to ensure SIGALRM is unblocked

We ran into an issue when using Python [subprocess](https://docs.python.org/3/library/subprocess.html) to call hping3 command under a Python web app server [uWSGI](https://uwsgi-docs.readthedocs.io/en/latest/), however the hping3 process hung forever.

It turned out that this malfunction ascribes to signal, uWSGI blocks SIGALRM, and fork(2) + exec(2) inherits the signal mask, so that the forked hping3 process starts with SIGALRM being blocked. Unfortunately SIGALRM plays a significant role in the hping app, and everything cracked.

According to SUSv4, it is recommended that signal sensitive software had better "assume that they start certain signals set unblocked":

> This volume of POSIX.1-2017 specifies that signals set to SIG_IGN remain set to SIG_IGN, and that the new process image inherits the signal mask of the thread that called exec in the old process image. This is consistent with historical implementations, and it permits some useful functionality, such as the nohup command. However, it should be noted that many existing applications wrongly assume that they start with certain signals set to the default action and/or unblocked. In particular, applications written with a simpler signal model that does not include blocking of signals, such as the one in the ISO C standard, may not behave properly if invoked with some signals blocked. Therefore, it is best not to block or ignore signals across execs without explicit reason to do so, and especially not to block signals across execs of arbitrary (not closely cooperating) programs.
(from susv4-2018/functions/exec)

Therefore I was wondering if it's appropriate to make some minor improvement to avoid further issues around this cause?