[core] Fixed a bug that responded a repeated conclusion HS with rejection

[ethouris]

Fixes Case 1 in #1648

[maxsharabayko]

Are both case 1 and case 2 of #1648 resolved by thes changes, or only case 1?

[ethouris]

Tested with case 1 only. I think case 2 is not covered because if a caller is "not convinced to be connected" and therefore still sends HS packets, it won't get any answer because the accepted socket won't send the answer simply because no one will dispatch the HS packet to it, as per having id=0. This requires another fix.

[maxsharabayko]

Updated description so that #1648 is not automatically closed after merging this PR.

[maxsharabayko]

A repeated HS CONCLUSION response has:

• Unset Destination socket ID (the value set is 0 instead of the known value of the caller socket)
• Weird Flow Window value 25600 instead of 8192.
• A timestamp copied from HS request instead of the listener's socket TS.

[maxsharabayko]

@ethouris Could you please set e.g. 2 seconds of RTT on some link and collect a network capture of the handshake to confirm the issue is resolved?
This will make a listener repeat its conclusion handshakes, and we will see if the fields listed above are correctly filled.

[maxsharabayko]

Had to perform the test myself. Confirmed that repeated Conclusion Response handshakes have valid content, including correct KMX message.