quic: correctly extend peer's flow control window after MAX_DATA

When sending the peer a connection-level flow control update in
a MAX_DATA frame, we weren't recording the updated limit locally.
When the peer wrote data past the old limit, we would incorrectly
close the connection with a FLOW_CONTROL_ERROR.

For golang/go#58547

Change-Id: I6879c0cccc3cfdc673b613a07b038138d9e285ff
Reviewed-on: https://go-review.googlesource.com/c/net/+/530075
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Jonathan Amsterdam <jba@google.com>

internal/quic/conn_flow.go

@@ -106,6 +106,7 @@ func (c *Conn) appendMaxDataFrame(w *packetWriter, pnum packetNumber, pto bool)
 		if !w.appendMaxDataFrame(c.streams.inflow.newLimit) {
 			return false
 		}
+		c.streams.inflow.sentLimit += c.streams.inflow.newLimit
 		c.streams.inflow.sent.setSent(pnum)
 	}
 	return true

internal/quic/conn_flow_test.go

@@ -35,6 +35,16 @@ func TestConnInflowReturnOnRead(t *testing.T) {
 		packetType1RTT, debugFrameMaxData{
 			max: 128,
 		})
+	// Peer can write up to the new limit.
+	tc.writeFrames(packetType1RTT, debugFrameStream{
+		id:   s.id,
+		off:  64,
+		data: make([]byte, 64),
+	})
+	tc.wantIdle("connection is idle")
+	if n, err := s.ReadContext(ctx, make([]byte, 64)); n != 64 || err != nil {
+		t.Fatalf("offset 64: s.Read() = %v, %v; want %v, nil", n, err, 64)
+	}
 }
 
 func TestConnInflowReturnOnRacingReads(t *testing.T) {