Possible signal handling issues

[Bart Schaefer <schaefer@brasslantern.com>]

Both of these have been around since at least 4.2.0.  Consider this script:

--- snip ---
sleep 20 &
TRAPINT() { set -x; kill -INT $$ }
wait
--- snip ---

Run that in the foreground, kill it with ctrl+c, and watch the infinite
loop.  Something to do with the "wait" command allows the INT to be re-
queued for handling even when it is sent from inside an INT trap.  The
signal_suspend() in zwaitjob() is constantly re-interrupted and never
returns.

I'm uncertain whether this next one is actually a bug.  This is from Chris
Johnson's question on zsh-users:

--- snip ---
sleep 10000 &
longpid=$!

sleepkill() {
  sleep 20
  print "timed out"
  kill $longpid
}

sleepkill &
sleeppid=$!

TRAPINT() {
  set -x
  kill $longpid
  #kill $sleeppid      # test 1
  #kill -- -$sleeppid  # test 2
  #kill -HUP -$$       # test 3
}
sleep 30
-- snip --

I avoided using "wait" as the last line there to show it's not related to
the previous bug.  If we run that script and then interrupt with ctrl+c,
the entire sleepkill function is left running in the background.  That's
probably correct because the monitor option is off in scripts so the hup
option does not apply.

Uncomment test 1.  Now the subshell started for sleepkill is terminated,
but "sleep 20" is left running.  This seems very odd to me, because that
sleep was never backgrounded relative to the sleepkill function.  Remove
test 1 and uncomment test 2 and you get a "no such process" error, which
indicates that sleepkill is not a "process group leader" so none of its
children receive its signals.  Uncomment test 3 which signals the whole
process group of the original script, and everything gets killed off.

Should the subshell be propagating that signal in the first test?