Refactors TCPMessage to have cleaner pathways

[CoryFoy]

Although we have fairly robust code in the networking retry logic there were still very occasional cases where TCPMessage would get disconnected (for example in a network change) and not reconnect. This cleans up the pathways into a set of three conditions:

1. If the TAKServer has changed (username, password, cert, server name, port) cancel the connection and do a reconnect
2. If we're in an "actively connecting / connected" state give it a little more time
3. If we're in a not actively connecting state (Waiting, Failed, Cancelled) force a reconnection attempt

There's a possibility that option 2 main have some edge cases we need some more work around, but in active testing across multiple network conditions we didn't have any drop/reconnect issues. Therefore this PR can be consider to close #13