Support for asynchronous TCP connections

[ryan-summers]

The current TcpStack trait doesn't facilitate well for a connect() operation that cannot be completed in a blocking manner. For example, a socket may have called connect(), but is_connected() may return false because the TCP handshake has not completed.

As such, it's required that an application repeatedly call connect() on a socket whenever is_connected() returns false to ensure that an active connection is being made. A single call to connect() may fail due to TCP state mismatch and other related problems within the network stack (see smoltcp-rs/smoltcp#367).

If the network stack isn't implemented to support repeatedly calling connect() on a socket that may already be connecting (but not yet connected), this can have unexpected consequences.

Is it possible for us to extend the TcpStack trait to either:

1. include an is_connecting() API
2. Modify the is_connected() API to return an enum indicating the state of the TCP connection (e.g. connecting, disconnected, or connected)
3. Have connect() return a non-exhaustive error enumeration that allows us to specify if a socket is already in the connecting process

I'm curious to hear some other thoughts on this as well. I'm looking to use these traits for an embedded MQTT client library that's targeting multiple network stacks (e.g. an external "hardware" network stack on a W5500 and a smoltcp network stack for a different device).

I've tried to describe the problem I'm having in an issue for minimq, which relies on a TCP network stack, so there's further context attached there.

[ryan-summers]

Perhaps the best approach to dealing with this is instead to return an error if the connect() method fails and then allow connect() to be a blocking operation. See #18