explicit read_timeout and write_timeout during hand/shake

[antiochp]

Resolves #3248.

We were blocking indefinitely on the initial hand/shake.
Once the peer is up and running for broadcast we will replace these timeout values with the existing settings for msg header and body reads and msg writes.

without these timeouts we see peer_connect threads stuck, blocked indefinitely waiting for read_exact on connections that may have closed suddenly.

[jaspervdm]

Given that the handshake reading is not in a loop like in the reader thread of poll(), it would mean that the connection is dropped if no message is received within HANDSHAKE_TIMEOUT. So in that case 2 seconds is maybe a bit too short.

[antiochp]

Given that the handshake reading is not in a loop like in the reader thread of poll(), it would mean that the connection is dropped if no message is received within HANDSHAKE_TIMEOUT. So in that case 2 seconds is maybe a bit too short.

That's a good point - this would need to cover the period waiting for a shake after first sending a hand msg to a peer as we immediately try to read from the stream after sending.
I'll set these both to 10 seconds and see how it behaves.
Or maybe we need different values for read and write - let me take another look.