congestion: saturate CUBIC window increment to avoid overflow

[LesnyRumcajs]

Resolves a panic:

`thread 'tokio-rt-worker' (2693719) panicked at /root/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/quinn-proto-0.11.16/src/congestion/cubic.rs:149:17:
  attempt to add with overflow

Cubic::on_ack computes cubic_cwnd += cubic_inc as u64 (congestion/cubic.rs:161). w_cubic grows cubically with the time since the last congestion event, so on a long-lived connection with no loss for roughly a week, cubic_inc exceeds u64::MAX and the addition overflows; a panic in builds with overflow-checks = true, a silent wrap otherwise.

Kind of along the lines of the ones below:

quinn/quinn-proto/src/congestion/cubic.rs

Lines 164 to 169 in fec2f89

	// Update the increment and increase cwnd by MSS.
	// Keep release builds from wrapping the retained credit.
	self.state.cwnd_inc = self
	.state
	.cwnd_inc
	.saturating_add(cubic_cwnd - self.state.window);

[Ralith]

Hmm, we shouldn't be increasing the congestion except when sending at congestion-limited rate, which should be pretty difficult to do without packet loss when your window gets big enough for this to be a threat. Still, this change is clearly reasonable.

[LesnyRumcajs]

Just for reference, this crash happened on a node running for around seven days, the entire thing running on a Digital Ocean VPS.

[djc]

Thanks!

Would you be able to submit a backport to the 0.11.x branch for this?

[LesnyRumcajs]

Would you be able to submit a backport to the 0.11.x branch for this?

Will do!