I/O Completion Port Networking

Rewrote the entire networking stack to switch away from
select-/poll-based networking.

The previous network stack worked like this:

The server would start up a ListenHandler on startup.  This component
would bind to all interfaces the server wanted to listen on, and then
use select on all the bound sockets with a 50ms timeout to wait for new
connections.  Every 50ms it'd time out, wake up, check a flag to see if
it was supposed to stop/shutdown, and then select again.

When a new connection was formed, it'd accept the connection, and then
dispatch an asynchronous callback, which it'd then poll in subsequent
wakeups, retrieve the result of, and if it was true, it'd dispatch
another asynchronous callback which did nothing but transport the socket
to the next component.  If it was false it'd disconnect the
newly-connected client.

If successful, a new client would be transported asynchronously to the
next component, ConnectionManager, which would also be started by the
server.  This ConnectionManager would fire a callback specifying that a
new connection had been formed, giving all server modules and components
the opportunity to react to this event.

It'd then add the connection to a queue, and wake up a "watcher" thread.

The watcher thread would poll a pool of ConnectionHandler objects, each
of which could be responsible for up to FD_SETSIZE connections.  If it
ever saw fewer open spots (through polling every 50ms and being woken up
whenever a new connection was added or a ConnectionHandler died) than
pending connections, it'd spawn a new ConnectionHandler.

The ConnectionHandler objects encapsulated two threads, one for sending
and one for receiving to/from up to FD_SETSIZE sockets.  The receive
thread would block on select (for up to 50ms), perform receives
(extracting all available data from each socket by looping on it until
poll reported there was nothing to be read), and extract new connections
from the pending queue.  The send thread would block on a condvar for up
to 50ms or until a send event woke it up, at which point it would pair
up sockets that poll reported could be sent on with connections that had
data to send, and then send them.  If this send failed to flush all data
out, it'd flag that socket for a resend, and go sleep again.

If at any point a ConnectionHandler had no connections, it'd kill
itself.

This had a few issues:

1. There was up to ~50ms of latency between accepting a connection, and
that connection actually getting any attention.  This is because there
was no way to actually add a socket to a handler, the socket had to
passively wait to be picked up by a handler, but this could take up to
50ms (since the handlers were blocking on select for up to that
duration).

2. If the server was empty, everytime the server was pinged it involved
spinning up two threads, receiving one packet, sending one packet, and
then killing those threads.

3. There was a lot of enumeration and copying going on.  In particular
the receive thread -- to avoid deadlocking the send thread -- had to
make a complete copy of its socket list everytime it looped.  It also
had to scan the whole socket list (to copy it and add all sockets to an
FD_SET), and then after select returned it had to scan every possible
combination between sockets in the list of sockets it owned and the list
of sockets in the FD_SET.

4. Polling.  Even if nothing was going on, all these threads were waking
up every 50ms.

Unfortunately I couldn't find a cross-platform solution to this problem.
The closest was a hack involving dummy sockets used to wake select calls
up before their timeout.

So I rewrote the whole network stack for Windows (Linux rewrite will
come later) using I/O Completion Ports.  It works like this now:

The server starts up a ConnectionHandler on startup.  This component
binds to all interfaces the server wants to listen on, creates an I/O
Completion Port, and then creates two threads -- an accept thread and a
worker thread.

The accept thread uses WSAWaitForMultipleEvents to wait on two events:
One which is set when it should shutdown (waking it up and stopping it
immediately) and one which is set whenever there's an FD_ACCEPT event on
any of the bound sockets.  WSAWaitForMultipleEvents allows the return
value of the function to determine which event actually woke it up, so
there's no checking flags, the thread just immediately dies when the
shutdown event is set (see src/network.cpp, lines 899-905).

If it was an FD_ACCEPT event on one of the sockets that woke the accept
thread up, it scans them and uses WSAEnumNetworkEvents to simultaneously
reset the events and detect which of the sockets has a pending
connection.

When it finds the socket that has the pending connection, it uses
WSAAccept to conditionally accept the connection by using a
server-provided callback to filter the results.  The OS then rejects the
connection if the callback returns false -- no connection is formed and
then immediately closed, there's no async dispatch, and no polling.

If the socket is accepted, it's bound to a Connection object, which adds
it to the I/O Completion Port.  A second callback -- which the server
provides and which notifies subscribers of a new connection -- is then
called asynchronously, and after it's called the I/O Completion Port is
posted a message telling it to begin looping receives on the socket.

The worker thread waits on the I/O Completion port, dequeuing both
asynchronous I/O completion packets, and messages that the other threads
post to tell it to manipulate sockets in some way.  When a receive is
completed it dispatches an asynchronous handler, which calls the
server-provided receive callback, and then orders the worker to issue
another asynchronous receive.

When any thread wishes to send, it calls a method on the Connection
object, which seamlessly moves (no copying) the buffer they wish to send
into a WSABUF object and dispatches an asynchronous send.  When this
completes the completion will be reported automatically through the I/O
Completion Port, which will handle error-handling/notification.

When the server shuts down, it posts a special message to the I/O
Completion Port, which causes the worker to die immediately.

This has many advantages over the previous model:

1. It can scale.  More worker threads can be spawned and seamlessly
multiplex the workload of the I/O Completion Port.

2. There's no polling.  Everything blocks until exactly when it needs to
wake up, so there's fewer wasted cycles.

3. Incoming connections get attention immediately (the latency of the
server on the Minecraft server select screen, running on localhost, went
from ~43ms to ~3ms with the replacement of the network stack).

4. There's no useless copying/enumeration.

5. Windows asynchronous socket operations will -- in many cases, since
once a buffer is handed to an asynchronous socket call that call is
considered to own it until it completes -- send/receive directly from/to
the buffers passed to them.  This means that as long as the server isn't
overburdened, the network stack is essentially no copy.  Data is
received directly into buffers, which are then dispatched, and data is
written directly from buffers, which can be moved in from callers
(incurring no copy).

I also rectified a problem in the old stack, which was that shutdown()
was never called on sockets, they were just closed.  Now, unless the
server is shutting down, all connected sockets will receive shutdown()
calls before they receive closesocket().

I plan to implement a similar model for Linux compatibility using epoll
once I bring RLeahyLib's Linux support up to snuff (the file system
enumeration abstractions used for finding/loading modules are currently
Windows-only).