Broadcom tester's were able to trigger a KASSERT in rack due to an accounting issue.

[rrs]

Summary

The recently added code to rack to help minimize reordering issues had a KASSERT for protection of its counting field. This
was consistently. Triggered in broadcom's testing lab. They came up with a partial solution.. but one of their fixes was
also incorrect causing the counter to increase incorrectly as well. I worked with them to give them an updated patch (the one
attached in this review). They have tested that in their same repro environment and confirm this fixes the issue.

Test Plan

Basically you test with reordering. Broadcom did it on a much larger
scale lab testing.. in any event you have to run with KASSERTs enabled (INVARIANCE on)
and make sure the counter does not go negative but also properly will reduce to zero
in the case of true reordering.

[tuexen]

This fixes PR 296474.
It would be great if this fix can go in soon, such we can get it into 15.2. Please refer to the PR.

[nickbanks_netflix.com]

sys/netinet/tcp_stacks/rack.c

5623

nit: recoveyr -> recovery