Intuition fix in clio_endpoint_recv (temporary).

The recv function, when combined with poll, behaves a bit
counterintuitively. Because we only recv when we know there is new
data on the socket (because of poll), we really want a non-blocking
receive call (using the MSG_DONTWAIT flag) to scoop all the sent data
and then signify there is no more data. If we pass no flags (ie 0)
then the recv call will block until the client hangs up or there's an
error, so looping on endpoint_recv while bytes > 0 will loop
forever. This is counterintuitive to what seems to be the
overwhelmingly expected case, given that, within an endpoint, we are
guaranteed to have data waiting.

So have silently disabled the flags argument and an just always using
MSG_DONTWAIT. Obviously, this is a bit of a hack. We need our own set
of flags and a translator between them to give the user more
control. And I don't want to simply remove the flags argument because
want to have that functionality available in future.
Sketch out clio_footprint function.

The idea here is to allow the user to set a memory limit on the server
as a percentage of the (total) system memory, either physical or
virtual. This ties in to having the server be aware of how much memory
it is using, which is a space I'd like to grow into. There area a lot
of questions here, and possibly a lot of knobs for the user to tweak.

Currently doesn't actually do anything...