on_close crashes in prod

[chiptus]

after commenting the code related to #436 our fatal errors reduced by a lot, but we still got too many.

a few days ago we added sentry with uploaded debug symbols so we can see the causes, and I'm sad to say it's still (motsly) socketIO.

we received the following alert 300 times, while all others are less than 10.

EXCEPTION_ACCESS_VIOLATION_EXEC / 0x181700019d81

ProjectAlpha-Win64-Shipping
+0x36ab55a
sio::socket::impl::on_close (sio_socket.cpp:372)

ProjectAlpha-Win64-Shipping
+0x36895a8
asio_handler_invoke_helpers::invoke (handler_invoke_helpers.hpp:37)

ProjectAlpha-Win64-Shipping
+0x36895a8
asio::detail::handler_work<T>::complete (handler_work.hpp:81)

ProjectAlpha-Win64-Shipping
+0x36895a8
asio::detail::wait_handler<T>::do_complete (wait_handler.hpp:71)

ProjectAlpha-Win64-Shipping
+0x368c515
asio::detail::win_iocp_operation::complete (win_iocp_operation.hpp:46)

ProjectAlpha-Win64-Shipping
+0x368c515
asio::detail::win_iocp_io_context::do_one (win_iocp_io_context.ipp:419)

ProjectAlpha-Win64-Shipping
+0x36bcae0
asio::detail::win_iocp_io_context::run (win_iocp_io_context.ipp:162)

ProjectAlpha-Win64-Shipping
+0x36bcae0
asio::io_context::run (io_context.ipp:61)

ProjectAlpha-Win64-Shipping
+0x36bd1e4
websocketpp::transport::asio::endpoint<T>::run (endpoint.hpp:642)

ProjectAlpha-Win64-Shipping
+0x36bd1e4
sio::client_impl<T>::run_loop (sio_client_impl.cpp:260)

ProjectAlpha-Win64-Shipping
+0x365643e
std::invoke (type_traits:1592)

ProjectAlpha-Win64-Shipping
+0x365643e
std::_Invoker_ret<T>::_Call (functional:670)

ProjectAlpha-Win64-Shipping
+0x365643e
std::_Call_binder (functional:1962)

ProjectAlpha-Win64-Shipping
+0x365643e
std::_Binder<T>::operator() (functional:1999)

ProjectAlpha-Win64-Shipping
+0x365643e
std::invoke (type_traits:1576)

ProjectAlpha-Win64-Shipping
+0x365643e
std::thread::_Invoke<T> (thread:55)

ucrtbase
+0x0029332
thread_start<T>
KERNEL32.DLL
+0x001257c
BaseThreadInitThunk
ntdll
+0x005af27
RtlUserThreadStart
```

might be related to #437 

[getnamo]

I'm starting to see this bug myself, will try to catch it in a debug session next time I'm working on the plugin to figure out what changed. This didn't used to happen, so some code change was introduced that has brought the instability in latest versions.