dist_ffi fixes and receive error handling

[RalfJung]

I figured it'd be a good time to go to the basics and (re-)consider our network / FFI model. In particular I wanted to make it so that Receive will actually return Err=true sometimes, namely when the socket is gone.

But then I realized that this doesn't make sense since when the socket is gone, we try to reconnect! So there's a discussion we need to have about which behavior we want dist_ffi to have. Should a channel created via Connect transparently reconnect? If yes, should Receive on such a channel ever return an error (and when)? Also when (if at all) should Receive on a channel created via Listen return an error?

From a uRPC perspective, it is quite nice that Send reconnects transparently and we anyway could not do much with the information that Receive failed. So maybe we should rename Err in ReceiveRet to Timeout and set some arbitrary timeout (60s) just to keep the operation fallible (which is required from a formal perspective), but not even attempt to actually provide information about network errors on the Receive side?

Also I realized the current "transparent reconnect" code is buggy -- or rather, it is racy; there could be other Send operations going on while we reconnect. So I added a lock to sender, which I then also use to avoid having to copy the data unnecessarily.

[RalfJung]

We're going to take a different approach to error handling that I'll implement shortly; let's close this one.