ipc-channel can deadlock on Linux

[glennw]

When a recv() is reading a fragmented message, the Linux implementation pushes any interleaved fragments from other messages back to the same file descriptor via sendmsg().

However, since that is being sent to the same fd, if the send buffer is full, deadlock occurs - because the send is occurring on the same thread that should be draining from that fd.

This causes a lot of timeouts in the webrender reftests, and (I suspect) is also responsible for a lot of the Linux timeouts we see on the build machines.

For example, see the backtrace below - thread 72 is blocked in sendmsg since the send buffer is full, but this is called inside of the recv() function for the same fd, so the send buffer will never be emptied.

(gdb) thread 72
[Switching to thread 72 (Thread 0x7fd63a3ff700 (LWP 9553))]
#0  0x00007fd644c875bd in sendmsg () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007fd644c875bd in sendmsg () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fd646b5ec41 in platform::linux::recv::h0111fbf8cc03dac2Mxb ()
#2  0x00007fd646b5d34d in platform::linux::UnixReceiver::recv::h76d3513f4fe3a26e2Ra ()
#3  0x00007fd6467af31f in render_backend::RenderBackend::run::h33e3f2df27cc03b3ULo ()
#4  0x00007fd646803bd8 in sys_common::unwind::try::try_fn::h13009946449717054376 ()
#5  0x00007fd64754d959 in __rust_try ()
#6  0x00007fd647549b2c in sys_common::unwind::try::inner_try::h62f00e3d34dbb509D3s ()
#7  0x00007fd646804d8b in boxed::F.FnBox$LT$A$GT$::call_box::h7120465612878348244 ()
#8  0x00007fd64754fc64 in sys::thread::Thread::new::thread_start::hb3a0514b9d87669e1mx ()
#9  0x00007fd642ed3182 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#10 0x00007fd644c8647d in clone () from /lib/x86_64-linux-gnu/libc.so.6

[glennw]

Fixed by #35