Using socket descriptor as an index works okay for UNIX, though it
wastes the first several indices which are assigned to STDIN/STDOUT,
files, etc. However, for Windows it is really bad, since descriptors are
large, nonconsecutive numbers. Using a little overhead to track each
iod's index and the next empty space is worth it.
1. pcap_get_selectable_fd() may return -1 for some devices, even if the
platform as a whole supports select() on these handles. Check for
this condition throughout.
2. The various backend system calls (kevent, poll, epoll, etc.) do not
sleep for the timeout period if no valid handles are registered,
unlike select on UNIX. This leads to busy wait, looping continuously.
Instead, we call usleep() in those cases.
For platforms without selectable pcap handles (e.g. Windows), the
arrival of data for a pcap read would previously skip checking for any
triggered non-pcap events in that loop iteration. This is not usually a
problem because the next loop will be triggered immediately, picking up
the non-pcap events before any further pcap data arrives. However,
excessive pcap data on a handle in immediate mode might prevent the
engine loop from checking for non-pcap events for long enough to result
in timeouts. Instead, do a non-blocking check for triggered events in
this case and handle those in the same loop iteration.
When the IOD isn't connected, iod->peerlen is 0, which means WSARecvFrom
returns WSAEFAULT because the lpFrom parameter is not NULL, and 0 bytes
is not enough space to fit any sockaddr.
SSL_WANT_READ and SSL_WANT_WRITE conditions modify the watched events during
NSE_TYPE_CONNECT_SSL, which was causing the IOCP engine to re-post the same
completion packet multiple times. Adding a status field to the
extended_overlapped struct resolves this.
Additionally, canceled and timed-out events risked the same extended_overlapped
being freed multiple times, which caused the gh_heap corruption in the original
issue report.
