Steps to reproduce:

1. Create a socket initiator that connects to a socket that does nothing
2. Start the initiator and observe that it connects to the socket
3. Stop the initiator before the reconnectinterval kicks in
4. Observe that the socket remains open

Background:

Recently we observed that during our session end schedule processing, a client will logoff on time ... we delay a bit, and then we close our socket initiator. In-between the time the client logged off and the time that we closed the socket initiator, a new socket connection was established to the client. This connection was "dead," e.g. it did not respond to FIX requests/responses. This dead socket remained connected until the next session start, where an additional socket was opened. Just after a new additional socket was opened, the client realized they had a dead connection open to us, and decided to close that dead connection.

We have special handling on SessionStateListener.onConnect() and SessionStateListener.onDisconnect(). When a new socket was created on the session start, SessionStateListener.onConnect() was called. This led us to believe everything was OK with this session. Then, when the dead socket was closed, SessionStateListener.onDisconnect() was called just after. This broke our internal logic because we thought this session was disconnected, when in fact it was operating normally.

To avoid this problem in the future, if rogue dead sockets are created, then it should be up to the initiator to close these sockets.