enb_proxy: fix stale SCTP events misprocessed during MME pool selection
When closing a connection to one MME and opening a new one to the next, a SHUTDOWN_COMP event from the old (now-closed) socket can still be pending in the process mailbox. The sctp_assoc_change handlers in the 'connecting' and 'wait_s1setup_rsp' states were matching '_Socket', ignoring the socket identity. A stale SHUTDOWN_COMP would therefore fall into the '_ -> repeat_state_and_data' branch, triggering a spurious re-entry of 'connecting', which immediately closed the newly established connection to the next MME and skipped to yet another pool entry.
Fix this by matching the Socket against the current S#state.sock in both handlers. Events arriving on a previously closed socket no longer match these clauses and are silently dropped by the catch-all handle_event/4.
This was found thanks to the MME pooling TCs in ttcn3-s1gw-test.