Support retry logic for clients

[chipsenkbeil]

For interactive clients, it would be useful to support retry logic versus immediate death when the network connection with the server is severed.

With UDP, there's no connection, so we don't worry about it. For TCP, there is a connection.

Note that running processes that are disconnected would also be killed by the server as part of connection cleanup.

[chipsenkbeil]

Add a reconnect method to a session. The session internally keeps track of the host, port, and key it used (if distant) and does a new connect internally, replacing the transport. That or we need to create an entirely new session because all of the tasks die. Maybe we can do an initialize and then swap out all of the fields.

For ssh, we can support a reconnect method, but it will trigger the handler methods again.

[chipsenkbeil]

We now have a means to reconnect to a server versus launching, but the logic for retry will most likely live in the manager that is handling connections. There may need to be a heartbeat request/response type added, going from server -> client as to avoid a client spamming heartbeat requests.

This is now a duplicate of #107.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.