Race in timely dataflow shutdown

[frankmcsherry]

@utaal observed that in situations where the communication threads are overloaded it is not unlikely that one process can complete all dataflows and exit before the communication thread has pushed the last of the progress messages to the other processes, causing them to hang in shutdown.

The root of the issue is that Rust's thread::spawn produces a result that if dropped detaches the thread, so that the main thread does not need to wait for it to complete before it exits. The send_loop thread is able to shut down, but the recv_loop thread runs forever and needs to have this result dropped (or be rewritten to notice when the socket closes).

@utaal had the proposal, which seems sane, that all we need to do is mem::forget the results from spawning the send_loop threads, as this is the only thread we need to keep alive (letting the recv_loop threads evaporate when the process exits should be fine, as we don't seem to need to receive to unblock other processes). The send_loop thread should exit when all of the MPSC send handles have been dropped (by workers), which should allow the main thread to exit cleanly but only once the send thread has sent everything it needs to send.

[frankmcsherry]

Note: this fix is not correct, owing to what not-detaching a thread doesn't do (it doesn't keep anything around, if the main thread exits).

Instead, the dataplane_mockup branch waits on all threads, communication and worker, which should ensure that all pending sends happen before the process goes away.

[frankmcsherry]

This should be fixed by #135.