Multithreading issues in PJSIP (thanks to Matt Williams for the report and expert analysis)

[ming]

1) pj_timer_heap_poll examines the timer heap’s current size without taking its
lock

As in the summary, pj_timer_heap_poll examines ht->cur_size before taking the
lock. Another thread could be manipulating this at the same time.

2) Possible deadlock due to “lock order inversion” between transport and
transaction locks
Normally, when sending a message, the transaction lock is taken (in
pjsip_tsx_send_msg), followed by the transport lock (in tcp_send_msg). However,
when sending the first message on a new connection, we receive a callback from
the ioqueue layer to say that the TCP connection is connected
(on_connect_complete), causing us to take the transport lock, and then take the
transaction lock (in send_msg_callback).
Taking locks in different orders in different places is a common cause of
deadlock so we would like to prevent that happening.

[ming]

In 4281:

Fixed #1592: Multithreading issues in PJSIP (fixing pj_timer_heap_poll() and lock order inversion in tcp/tls transport)

[ming]

In 4394:

Re #1592: Backported to 1.x