Document why the socket send buffer size is being limited here.

When doing it via write(), it's fine to leave it at the system default.

When doing it via sendfile(), we're getting notified by the kqueue
write notification when the socket can accept more data - NOT when
the write has completed.

Next, we only have one send buffer right now in srv/clt, so in the
sendfile case, it's going to be just queuing that over and over again
to the same socket.  Not very good - we'll end up wiring the same
VM page(s) to lots of different mbufs over and over on the same socket.
It's not exactly what we're going to be doing in production.

So for now, let's limit the send buffers size to the page size that
we're writing.  That alleviates the duplicate page writing a bit.
I'll then add the sendfile kqueue notification mechanism to the mix
and use that to note that the sendfile write path has completed.
Once that's done, we can combine the normal socket write readiness
and the sendfile completion notification to know (a) when to
schedule more stuff, and (b) when an existing transaction has
actually, completely finished transmitting.

It's all dirty. I dislike it, but..