sctp: Fix races around sctp_inpcb_free()

sctp_close() and sctp_abort() disassociate the PCB from its socket.
As a part of this, they attempt to free the PCB, which may end up
lingering. Fix some bugs in this area:

• For some reason, sctp_close() and sctp_abort() set SCTP_PCB_FLAGS_SOCKET_GONE using an atomic compare-and-set without the PCB lock held. This is racy since sctp_flags is normally updated without atomics, using the PCB lock to synchronize. So, the update can be lost, which can cause all sort of races with other SCTP components which look for the _GONE flag. Fix the problem simply by acquiring the PCB lock in order to set the flag. Note that we have to drop and re-acquire the lock again in sctp_inpcb_free(), but I don't see a good way around that for now. If it's a real problem, the _GONE flag could be split out of sctp_flags and into a dedicated sctp_inpcb field.
• In sctp_inpcb_free(), load sctp_socket after acquiring the PCB lock, to avoid possible races with parallel sctp_inpcb_free() calls.
• Add an assertion sctp_inpcb_free() to verify that _ALLGONE is not set.

Reviewed by: tuexen
Sponsored by: The FreeBSD Foundation

(cherry picked from commit c17b531bedd10c7ebea08919fd73ee708ff37336)