Rendezvous Connection in the Non Blocking Mode

[maxsharabayko]

There appears to be a bug in the rendezvous handshake flow of SRT. Checked with the latest master and SRT v1.4.2. I expect earlier versions are affected as well.
The bug is not critical because a connection still can be established. Just the flow is not totally correct and in a certain case establishing a connection would take longer: ~(2,5×RTT + 250 ms) instead of 1,5×RTT.
On the left is the expected (correct) rendezvous HS flow that happens in the blocking mode of SRT receiving (SRTO_RCVSYN=true).
Connection is established in 1,5×RTT (from the time both peers are up and running).
On the right is the (incorrect) rendezvous HS flow that happens in the non-blocking mode of SRT receiving (SRTO_RCVSYN=false).
Connection is established in (2,5×RTT + 250ms) from the time both peers are up and running.
It is however not a critical issue, because the connection is still established.

Reason for WAVEAHAND instead of CONCLUSION REQ

The initial WAVEAHAND does not have a DST SRT Socket ID, the following condition is true:

        if (i->id != dest_id)
        {
            read_st = RST_AGAIN;
            conn_st = CONN_AGAIN;
        }

Setting conn_st = CONN_AGAIN forces another WAVEAHAND instead of CONCLUSION_REQ.