Refactor keep-alive process logic.

[provrb]

When a keep alive echo is received, the old logic used to compare the size of the encrypted received data with a default encrypted keep alive packet. One major flaw in this is that encrypted data, regardless if it's a packet or client request, will be 512 bytes in size when encrypted with the RSA request keys (4096 bit keys), this logic causes improper checking and can mistake any encrypted data for a successful keep-alive echo.

Furthermore, in the receiving logic, SendKeepAlivePackets(long cuid) and TCPReceiveMessagesFromClient(long cuid) would both be receiving at the same time. Thus, TCPReceiveMessagesFromClient would actually receive the Packet and not SendKeepAlivePackets. Take advantage of this by removing the ReceiveData() call in SendKeepAlivePackets, and just set a flag in the client when a keep alive packet is received while the KeepAliveProcess flag is set to true when we receive data in TCPReceiveMessagesFromClient. This allows for better readablility, and more efficient code. In SendKeepAlivePackets(), we can use Sleep(), and consistently check if

1. The time passed has not exceeded the timeout without a response
2. KeepAliveSuccess flag in the client is still false
3. KeepAliveProcess flag is equal to true. We are still waiting.
   If all of these are successful, we have received a valid response. Otherwise, keep waiting and them declare a time-out by the client.

Overall, this new logic is more efficient compared to the old code, and more readable, with TCPReceiveMessagesFromClient doing all the receiving and SendKeepAlivePackets doing all the sending and handling timeout.