The linger option to TCPConn doesn't work as we expect especially "If sec > 0,
Close blocks for at most sec seconds waiting for data to be sent and acknowledged."
part because current  TCPConn.Close implementation never blocks anything instead of
retuning syscall.EWOULDBLOCK or similar.

func (fd *netFD) Close() error {
        (snip)
        // Unblock any I/O.  Once it all unblocks and returns,
        // so that it cannot be referring to fd.sysfd anymore,
        // the final decref will close fd.sysfd.  This should happen
        // fairly quickly, since all the I/O is non-blocking, and any
        // attempts to block in the pollDesc will return errClosing.
}

Other matters to be attended to;

- A conventional issue on TCP socket closing w/ lingering. When we call TCPConn.Close to
SetLinger(0) configured sockets on active-close side, TCPConn.Read on passive-close side
returns syscall.ECONNRESET or similar instead of io.EOF because lingering usually causes
sending RSTs. It really depends on underlying protocol stack implementation, though.

- Another conventional issue on TCP socket closing w/ lingering. SetLinger(sec > 0)
usually causes 2MSL close wait, SetLinger(sec > 0) configured sockets remain inside
the kernel for a short time (2MSL).

Perhaps we should encourage people not to use SetLinger and recommend to use CloseRead,
CloseWrite instead.