tcp: calc ssthresh on RTO according to RFC5681

[rscheff]

Summary

Cwnd only reflects flightsize when the first RTO
happens suddenly, but not during loss recovery.

RFC5681 states that FlightSize should be used to
adjust ssthresh to - and when an RTO happens during
FastRecovery or SACK Loss Recovery, cwnd is typically
mangled to dole out the expected retransmission or
new transmission - but not the actual FlightSize (pipe).

RFC5681 is also clear to not adjust ssthresh on
any subsequent back-to-back RTOs (only the first RTO).

This snippet of code would have to be replicated into
newreno.c, htcp.c, cubic.c, dctcp.c with the appropriate
adjustments.

[rscheff]

• expand rfc5681 rto ssthresh calc to all relevant places.
• and also in rack

[rgrimes]

Ifyou open a review and tag a person into that review you should wait at least 24 hours before you commit the code, giving that person time to respond.

Only technical comment I have is the type change on mss, do we consistently store this as uint32_t, or does this change introduce some place are using u_int for it and this code is using uint32_t? I know that for the present platforms these are the same, but the future may not forever hold that. Also, isnt mss really a 16 bit value? TCP header spec says type 2, 4 byte option, which I dont get either, as this is suppose to be derived from MTU and MTU is a 16 bit value by IP spec. Anyway already committed so Meh.