close channel only after queues have stopped their workers, fixes bar…

…chart#83

Otherwise, the socket is closed and the file descriptor is freed prematurely.
Due to a race condition the queues might then still be trying to use the old
file descriptor which by now may already point to another unrelated socket. This
may either lead to "stolen" data, data that is read accidentally by the
queue worker for the already closed socket. Or it may lead to a complete deadlock,
if the file descriptor now points to a blocking socket, so that
`delete m->second.m_pRcvQueue` will never return because it joins the worker
thread which blocks indefinitely on the wrong socket. After some time this
deadlock will bring UDT completely to a halt because the above code holds the
m_ControlLock into which all other work will run and block there after a while.

(cherry picked from commit ccb843e)

barchart-udt-core/src/main/c++/udt/src/api.cpp

@@ -1305,10 +1305,10 @@ void CUDTUnited::removeSocket(const UDTSOCKET u)
    m->second.m_iRefCount --;
    if (0 == m->second.m_iRefCount)
    {
-      m->second.m_pChannel->close();
       delete m->second.m_pSndQueue;
       delete m->second.m_pRcvQueue;
       delete m->second.m_pTimer;
+      m->second.m_pChannel->close();
       delete m->second.m_pChannel;
       m_mMultiplexer.erase(m);
    }