RaceToDeath - fixing a potential race condition

There was a potential race in a scenario where the user would call `stop` on an already disconnected connection and `start` on the same connection but on a different thread. In that case the call to `stop` would unconditionally null out the transport but since this was not happening in the lock the transport could have been set in the concurrent `start` request so nulling it out would cause a crash. To fix this we are taking a lock to block the start request and resetting the transport only if the previous state was `disconnecting` for cases where the starting connection already went past the lock (and therefore changed the state to 'connecting`)