Track a sequence number for non-DSR packets.

Summary:
This is essentially a further extension of the previous idead of having a sequence number per-DSR stream.

The rationale is the same -- to reduce spurious loss declared from the reordering threshold.

The primary case this works around is the following

```
<!DSR><!DSR><!DSR><DSR><DSR><DSR><!DSR>
```

Suppose we get an ACK for [0-1,3-5] leaving only packet number 2 remaining.

The naive reordering threshold will declare packet number 2 as lost. However, in principle this is arguably wrong since when considered on the timeline of !DSR packets, the gap does not exceed the reordering threshold.

To accomodate this we need to track a monotonically increasing sequence number for each non-DSR packet written, and store that in the packet metadata. This way we can use that for the reordering comparison rather than the packet number itself.

When there is no DSR packets ever written to a connection this should devolve to an identical result to using the packet number, as they will increment together.

Reviewed By: kvtsoy

Differential Revision: D46742386

fbshipit-source-id: 2983746081c7b6282358416e2bb1bcc80861be58

quic/state/test/QuicStateFunctionsTest.cpp

@@ -1228,7 +1228,7 @@ TEST_F(QuicStateFunctionsTest, EarliestLossTimer) {
 
 TEST_P(QuicStateFunctionsTest, CloseTranportStateChange) {
   QuicConnectionStateBase conn(QuicNodeType::Server);
-  getAckState(conn, GetParam()).nextPacketNum = kMaxPacketNumber - 2;
+  getAckState(conn, GetParam()).nextPacketNum = kMaxPacketNumber - 1;
   EXPECT_FALSE(conn.pendingEvents.closeTransport);
   increaseNextPacketNum(conn, GetParam());
   EXPECT_TRUE(conn.pendingEvents.closeTransport);