Fix issue where slaves could hang believing they were connected

If more slaves were running than a master required, they could go into a
state where they receive a session-matching broadcast and connect back to
the master. This TCP connection would be established against a socket that
has been bound to an interface and set to listen for connections. Because
there are no guarantees that the master has actually accept()ed the
connections, a scenario could arise where the master's kernel has accepted
the connection on the application's behalf. That is, SYN+ACKs would have
been sent by the kernel, but the connection was never really accepted by
the application.

When the master exists, RST packets are not sent to slaves in this state
until they try to write to the socket. Due to the way synexec's protocol
work, such a scenario could lead to slaves hanging for a very long time.

This patch addresses this issue and a few other issues that came about
once this was fixed.