The implementation comparing remote_ip.addr && remote_port to determinate
if the request is a new_peer or not.
We have observed some cases that the checking got wrong result.
The root cause is when got a zero length new_peer, current code sends
WICED_TCP_CONNECT_CALLBACK_INDEX asynchronous event.
Given the nature of asynchronous event we don't know when the other thread
will finish handling the connect event, it's possible that next packet is coming
before the code to handle previous CONNECT event.
Thus the upcoming packets are run into wrong state.
1) zero_length packet -> new_peer: send CONNECT event
2) non-zero length packet -> !new_peer (receive): send RECEIVE event
3) zero length packet -> !new_peer (disconnect): send DISCONNECT event
Wrong state case:
1) zero_length packet -> new_peer: send CONNECT event ( but accept is not yet called or finished)
2) non-zero length packet -> still new_peer (because another thread calling accept is not yet finished, remote_ip.addr/remote_port are not yet updated).
3) zero_length packet -> if another thread calling accept is not yet finished it will still be new_peer, thus send CONNECT event again.