This attempts to address issue #1993.

With this change, all stream I/O is moved to the head of get_binary_packet, with applicable timeouts applied, and processing of the payload only commences once read in full. This ensures that an under-read of the remainder of the packet from the stream does not lead to false-positive errors during subsequent processing, as with e.g. potential for decrypt errors in handling of the $tag value in GCM/ChaCha decrypt logic. The partial packet is also buffered in the repurposed binary_packet_buffer such that graceful re-entry into get_binary_packet is accommodated during timeout events, where packets previously could be lost and client corruption was a possibility with the remainder of the packet left in the buffer.

The $skip_channel_filter parameter is removed from both get_binary_packet and filter method signatures. It was previously used to enact timeout enforcement at the head of get_binary_packet, but became extraneous to that end with the added timeout enforcement of c20dd78 and its predecessor, i.e. with all paths through get_binary_packet now enforcing timeouts. Some channel packet type cases (MessageType::CHANNEL_DATA, MessageType::CHANNEL_EXTENDED_DATA, MessageType::CHANNEL_CLOSE, MessageType::CHANNEL_EOF) were removed from filter() packet processing, deemed extraneous considering that exec() no longer consumes get_binary_packet directly, as was the case when a3325d1 was authored, preferring get_channel_packet, and that get_channel_packet already loops over get_binary_packet to prompt fetch of the next packet under appropriate circumstances, i.e. such as receipt of packet on another channel. This allowed for some cleanup within get_channel_packet as well.

The exception InvalidPacketLengthException is introduced and thrown from the added get_binary_packet_size when encountering a bad packet_length value. This maintains handling of the OpenSSL 0.9.8e issue (reported in #1171 , changed with e5b4eef) from within _login_helper without importing the knowledge of the issue into low-level packet processing. Validation is added for a packet_length value of 0 or negative value.

Lastly, reset_connection and disconnect_helper are reorganized such that any use of disconnect_helper will now prompt reset of the SSH2 instance, or at least of what was previously captured by reset_connection, and including binary_packet_buffer and added keep_alive_sent.

Through the added SSH2 functional test testCryptoAlgorithms(), I was able to test the following algorithms and also provide decent coverage of the changes. See attachments coverage-getbinarypacket-crap4j.txt and coverage-getbinarypacket-cobertura.txt for excised coverage analysis of the functions get_binary_packet and get_binary_packet_size. Lack of coverage is mostly reflected in the error/breakout states, debug logging, and the zlib compression implementation, however unmodified here.

KEX:
- curve25519-sha256
- curve25519-sha256@libssh.org
- ecdh-sha2-nistp256
- ecdh-sha2-nistp384
- ecdh-sha2-nistp521
- diffie-hellman-group14-sha256
- diffie-hellman-group14-sha1
- diffie-hellman-group1-sha1

HostKey:
- rsa-sha2-256
- rsa-sha2-512
- ssh-rsa

Crypt:
- aes128-gcm@openssh.com
- aes128-ctr
- aes192-ctr
- aes256-ctr
- chacha20-poly1305@openssh.com

MAC:
- hmac-sha2-256-etm@openssh.com
- hmac-sha2-256
- hmac-sha1-96
- hmac-sha1

In order to prompt testing of the chacha20-poly1305@openssh.com encryption algorithm, I had to comment out this logic in getSupportedEncyrptionAlgorithms(). I only dug a little, but it looked to me like chacha20-poly1305@openssh.com might not be viable according to this as it doesn't provide a setupInlineCrypt() method or invoke createInlineCryptFunction(). Something to look into perhaps.

case 'chacha20-poly1305@openssh.com':
case 'arcfour128':
case 'arcfour256':
if ($engine != 'Eval') {
    continue 2;
}
break;