Add KASSERT()s, as suggested by glebius@.

Hi Peter,
thanks for letting us know that one can also trigger these issues with the TCP stress tester. Will try to reproduce it with and without fixing the root cause. There might be more than one problem and I prefer to fix them individually instead of avoiding them altogether...

In D48652#1109741, @rscheff wrote:

Well, if the RTO was indeed spurious, then the subsequent RTO timeout should be the base RTO timeout (again). So, only a false detection of a spurious timeout would (incorrectly) set the cadence to a slightly faster retransmission schedule in subsequent rounds... But if the RTO was spurious, so by definition shouldn't have been triggered anyway, I don't believe this causes a problematic behavior.

Wouldn't be the RTO after an erroneous RTO be computer incorrectly? Let me write a test for that...

In D48346#1103376, @cc wrote:

Why not move the old_method: label above the stack variables' declaration? I think it may be cleaner to read.
Like this:

	old_method:
		uint64_t cwnd, tr_perms = 0;
		int32_t reduce = 0;

Address comment raised by Peter. Coverity also reported it, which I overlooked.