If a socket is closed and the remote side sends a RST before the local
side sends its own RST, it is possible to jump directly from FIN-WAIT-1
to CLOSING without ever sending a RST to the remote side.

The main side effect is that if untransmitted data is present, the
socket is never exhausted, causing `EthernetInterface::poll` to loop
forever.

The ideal fix is to follow RFC more closely and not transition to
FIN-WAIT-1 until the RST has been sent, but there are too many
assumptions based on the current state that would be broken by remaining
in ESTABLISHED with a closed transmit buffer to be worth fixing
a relatively rare edge case. Instead, add another illegal transition to
fix the failures of a previous violation, in the spirit of all good TCP
stacks.

In the FIN-WAIT-2 state, we have closed the transmit side of our
connection with acknoledgement from the remote side, but we may still
receive data from the remote side. The motivating example is a simple
request/response protocol where the client sends a RST immediately
after its request before/during the server's response.

Forcing calling code to loop reduces socket processing latency for the
calling code, but this does break the currnet API as you now only
want to wait to poll again when socket readiness stops changing.

Greater than 3 sACK blocks is seen on real devices. Bumping up to
4 which is the maximum permitted in any case.