kqueue: simplify knote_fdclose() and avoid a possible fork-deadlock

[kevans]

Summary

kqueue_fork_copy() is likely to have transitioned at least one knote
through a flux state, so it's worth checking whether we need to wake
anything up on the way out.

The influx logic in knote_fdclose() is a little misguided, the resulting
wakeup() call should always be redundant: knote_drop_detached() will
always issue a wakeup before it returns, so anything waiting on *that*
knote that had entered fluxwait should have been woken up then. This is
the obvious divergence from the other influx/wakeup pattern in the
implementation, which will kn_influx-- and then issue the wakeup after
it has processed all of the knotes it can make progress on.

While we're here, the kq_knlist cannot shrink, so we can avoid that
condition in the loop and avoid potentially excessive wakeups from
fluxwait on kqueues that we didn't touch.

[kib]

I think that kqueue_fork_copy() should be committed separately (no need for the new review, I am only asking for splitting the commit).

[kevans]

In D56210#1285782, @kib wrote:

I think that kqueue_fork_copy() should be committed separately (no need for the new review, I am only asking for splitting the commit).

Sure, I'll split the commit message the sensible way (with the first paragraph re-worded slightly):

kqueue: avoid a possible fork-deadlock

kqueue_fork_copy() is likely to have transitioned at least one knote
through a flux state, so we should check whether we need to wake
anything up on the way out to avoid a possible deadlock.