Increment record layer sequence number when retransmitting DTLS packets

Hi,

Your solution to the epoch issue (commit 05f11c4) isn't going to work. The record layer sequence number should be incremented also on retransmitted packets, says the RFC. What's less clear is what to do with epoch/sequence number on the Finished message; if the receiver never got the CCS+Finished flight, did the epoch change ever happen? What OpenSSL does here is to send Finished with the new epoch, but wait until the other end has answered before actually changing its state. The result is that the Finished message of the initial handshake is always sent as epoch 1, seqno 0, no matter how many retransmissions are made. I don't know how mature that DTLS implementation is, but to me it feels like a sensible way to go about epochs and sequence numbers.

I tested this change against the OpenSSL example server, dropping different packets during the handshake.