Fix two issues with net tcp command:
* The `net tcp` commands are still based on net_context API. For TCP,
the API caller (net shell) should add one extra reference to the
allocated net context, to prevent premature context release in case of
connection teardown. Currently that was not the case, and the context
was released too early, resulting in missing final ACK from the Zephyr
side on connection close.
* The net context API should not be called from the registered connect
callback, as this creates a temporary deadlock situation. The
net_context_connect() function blocks until the connection is
established, or an error or timeout occurs. For that time the
net_context mutex is being locked. In case of connection error (for
example after receiving RST packet) the connect callback is called,
indicating an error. If we try to call net_context API from within, a
deadlock situation takes place, as the context mutex is still locked
by the net_context_connect() (called from the shell thread). This
blocks the further execution of the TCP stack and can result in an
unexpected behavior (like for example retransmitting the SYN packet,
which takes place from yet another thread, TCP work queue).
Fix this, by releasing the net context not from the callback directly,
but based on the return value from net_context_connect().
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
05361edb1b