[FIX] Added rejection handshake sent to the peer in rendezvous mode

[ethouris]

This adds the procedure to craft and send the rejection response in case when the handshake in rendezvous mode in one side has resulted in rejection. Some paths for this are common with caller mode so it's taken care of that it happens only in case of rendezvous mode.

Motivation: in case of caller-listener layout, it happens the following way:

1. Caller-Listener induction exchange.
2. The listener receives conclusion handshake, which is erroneous and it is being rejected
3. The listener responds anyway (in its distinct procedure), AFTER it closes the accepted socket without allowing it to be retrieved, and the listener handler procedure is crafting and sending the rejection response to the caller.

In some rare cases when the rejection is done on the caller, while the listener accepts the handshake, the caller doesn't send any rejection handshake to the listener (and sends the shutdown message instead) because:

1. The listener has finished and it will not handle this message. This will be dispatched to the accepted socket.
2. The accepted socket now expects only data packets or some in-transmission control packets (including obviously shutdown), and not the handshake. It has already accepted the connection so no rejection could be handled this time (the application that is using this socket has already put it into the procedures using recv/send procedures, and these are not intended to return any "rejection", at worst they can find the socket disconnected).

Hence:

1. The listener already has a procedure that sends back the rejection handshake.
2. The caller can't send the rejection handshake to an already connected peer, only shutdown.

In rendezvous the situation is a little bit different: both sides handle the request in their procedures working the same way as for caller, with a special procedure handling the rendezvous part. So there wasn't so far defined any way to send any rejection packet to the peer - but then it was possible to add this only for the path referring to rendezvous connection. Unlike for the caller, it does make sense here to send the rejection handshake because it is always the first arrived conclusion handshake with extension that ignites the connection and it is awaiting a response, be it even of AGREEMENT type.

[maxsharabayko]

Rendezvous, blocking mode now sends both HS Rejection and SHUTDOWN.
Rendezvous, non-blocking mode now sends only HS Rejection and no SHUTDOWN.

I don't think a SHUTDOWN should be sent. But now the behavior is (still) a bit inconsistent between blocking (HS REJECT + SHUTDOWN) and non-blocking (HS-reject) modes.

Not sending a SHUTDOWN seems a bit more complicated, but probably more correct. A condition should be added detecting rejection and rendezvous in queue.cpp line 957.

Sending a SHUTDOWN in non-blocking mode is easier: just remove the break statement. But maybe not correct, because there is no connection established yet.