tcp: Check if we exceed socket send buffer instead of snd_fack

[rscheff]

Summary

SACK rescue retransmission is supposed to be inserted never
exceeding the right edge of the socket sendbuffer. However,
rarely there appear to be instances, when either the rescue
retransmission is created using an incorrect offset (FIN bit?),
or the send buffer retracts (?). In this case, panic an INVARIANTS
kernel as early as possible to track why this may be happening,
or skip over SACK retransmission processing altogether and revert
to NewReno loss recovery from snd_una.

[rscheff]

• verify the creation of the rescue retransmission hole in the scoreboard

[rscheff]

• make sure that snd_max is never more than 1 beyond so_snd

[rscheff]

• make snd_max sane in non INVARIANTS build while warning

[tuexen]

sys/netinet/tcp_output.c

1573

Please declare so at the beginning of a block.

1576

Use top + 1 instead of top+1.

1659

Please declare so at the beginning of a block.

sys/netinet/tcp_sack.c

901

Please declare so at the beginning of a block.

984

Why do you start a block here?

985

Please declare so at the beginning of a block; assuming you remove the start of the current block.

[rscheff]

• align code with style rules

[rscheff]

thanks for the feedback, addressed the comments.

[rscheff]

• revive D2970 - adjust snd_nxt properly if FIN packet fails to be sent

[rscheff]

• add logging, when D2970 fix activates - to check incidence rate

[rscheff]

The combination of D36626, D36631 and D36637 addressed the root cause (and incidential, connected issues). This symptomatic fix is not needed.