EPoll error capture - store in NetEvent for later processing.

[SolidWallOfCode]

Testing some HostDB issues, it turns out that if there is an error reported epoll that is simply dropped on the floor and the error isn't detected until a subsequent I/O operation. The best way to handle this is debatable, but it was agreed the first step is to store the error in a way that can be found in later processing.

With the current code if the socket is being checked for being writable, on error epoll will report both writable and error. Because the error indication is dropped, this generates a WRITE_READY as if there were no error. This in turn causes the state machine to validate the TCP handshake even though it did not occur, which means the subsequent error on writing the proxy request causes a 502 response to the user agent but has no effect on marking the upstream as dead.

@shinrich notes that we may want to handle this differently for read vs. write, because in a read situation there may be useful data on the socket, but that's never the case for a write. Therefore it might be reasonable to ignore the error for read, but signal it for write.

[SolidWallOfCode]

Further testing reveals this is a problem when there is a negative ICMP response. In that case epoll reports an error. This is a bit more serious as it would be quite reasonable in this case to indicate the upstream IP address is dead.

[SolidWallOfCode]

Superceded by #7809.