Add more aggressive DTLS replay tests.

The existing tests only went monotonic. Allow an arbitrary mapping
function. Also test by sending more app data. The handshake is fairly
resilient to replayed packets, whereas our test code intentionally
isn't.

Change-Id: I0fb74bbacc260c65ec5f6a1ca8f3cb23b4192855
Reviewed-on: https://boringssl-review.googlesource.com/5556
Reviewed-by: Adam Langley <agl@google.com>
diff --git a/ssl/test/runner/common.go b/ssl/test/runner/common.go
index 07cb175..6c10992 100644
--- a/ssl/test/runner/common.go
+++ b/ssl/test/runner/common.go
@@ -589,11 +589,11 @@
 	// error if the server doesn't reply with the renegotiation extension.
 	RequireRenegotiationInfo bool
 
-	// SequenceNumberIncrement, if non-zero, causes outgoing sequence
-	// numbers in DTLS to increment by that value rather by 1. This is to
-	// stress the replay bitmap window by simulating extreme packet loss and
-	// retransmit at the record layer.
-	SequenceNumberIncrement uint64
+	// SequenceNumberMapping, if non-nil, is the mapping function to apply
+	// to the sequence number of outgoing packets. For both TLS and DTLS,
+	// the two most-significant bytes in the resulting sequence number are
+	// ignored so that the DTLS epoch cannot be changed.
+	SequenceNumberMapping func(uint64) uint64
 
 	// RSAEphemeralKey, if true, causes the server to send a
 	// ServerKeyExchange message containing an ephemeral key (as in