Use IO#read rather than repeated calls to Socket#recvfrom

Turns out this method is a bit of a hot spot (see @vmg's excellent investigations over at https://github.com/github/github/issues/31521#issuecomment-56088039).

Using IO#read with a Ruby timeout reduces the time taken to serve a 100mb blob from 14.4 seconds to 3.5 seconds on a lab machine.

cc @github/perf @github/gitrpc
I think this doesn't have the same semantics as the previous call. We use the timeout to avoid blocking too long on a socket read (because we're gonna call `recv` several times). `IO#read` also calls `recv` several times, but since the whole call is wrapped in a `Timeout` block, this is going to limit how long we can be actually *reading data* from the socket.

I'm afraid this will cause long reads to abort even through they are *actively reading data* from the socket. The workaround would be pretty straightforward: simply set `SO_RCVTIMEO` on the socket, and all the `recv` calls will timeout by the kernel. From the manpage:

> Specify the receiving or sending timeouts until reporting an error. The argument is a struct timeval. If an input or output function blocks for this period of time, and data has been sent or received, the return value of that function will be the amount of data transferred; if no data has been transferred and the timeout has been reached then -1 is returned with errno set to EAGAIN or EWOULDBLOCK, or EINPROGRESS (for connect(2)) just as if the socket was specified to be nonblocking. If the timeout is set to zero (the default) then the operation will never timeout. Timeouts only have effect for system calls that perform socket I/O (e.g., read(2), recvmsg(2), send(2), sendmsg(2)); timeouts have no effect for select(2), poll(2), epoll_wait(2), and so on.

I think this is exactly the behavior we want (and the behavior we had before these changes).

tl;dr: drop the `Timeout` block