fix(rpc): ignore sigpipe on linux

[rgrinberg]

We ignore sigpipe by sending messages with sendmsg with the appropriate flag.

All of this requires us to get rid of the Out_channel, but this desirable anyway, since we'll need it gone for evented IO.

[nojb]

LGTM (I left a few comments)

One point that I would be careful with is that the buffers seem to be long-lived, but there is no facility for "shrinking" them, which means that memory usage will only increase for them. This may become a problem in certain scenarios, right?

[nojb]

Suggested change

	let written =
	let bytes = Io_buffer.bytes out_buf in
	let pos = Io_buffer.pos out_buf in
	let len = Io_buffer.length out_buf in
	try write fd bytes pos len
	with exn ->
	Mutex.unlock write_mutex;
	reraise exn
	in
	Io_buffer.read out_buf written;
	Mutex.unlock write_mutex;
	let bytes = Io_buffer.bytes out_buf in
	let pos = Io_buffer.pos out_buf in
	let len = Io_buffer.length out_buf in
	match write fd bytes pos len with
	| written ->
	Io_buffer.read out_buf written;
	Mutex.unlock write_mutex;
	csexp_write_loop fd out_buf token write_mutex
	| exception exn ->
	Mutex.unlock write_mutex;
	reraise exn

[nojb]

A second question is that we repeatedly lock/unlock the mutex on each iteration of the write loop; is this better than holding on to the mutex until the writing is done? (eg by using a local function)

[rgrinberg]

I think it's better because it's allowing callers to refill the write buffer on every send. Less write calls and more mutex locks sounds like a better trade off. Anyway, the mutex will be gone soon so I suggest we don't dwell on it.

[rgrinberg]

One point that I would be careful with is that the buffers seem to be long-lived, but there is no facility for "shrinking" them, which means that memory usage will only increase for them. This may become a problem in certain scenarios, right?

There's natural push back on writing. I tweaked it to stop doubling past a certain size. That should restore the size after sending particularly large.