tcp: Rack at times can miscalculate the RTT from what it thinks is a persists probe respone.

[rrs]

Summary

Turns out that if a peer sends in a window update right after rack fires off
a persists probe, we can mis-interpret the window update and calculate
a bogus RTT (very short). We still process the window update and send
the data but we incorrectly generate an RTT. We should be only doing
the RTT stuff if the rwnd is still small and has not changed.

Test Plan

We can use packet drill to generate the situation but will have to
examine the BB logs to validate that the invalid RTT measurement
is not made.

[rrs]

Opps there is another issue here, a double bump of rtt_shift that should not be when persists happen. Only
bump it in the timer code.