Possible crash due to transaction premature destroy while message send operation is on progress

[nanang]

There is no protection for premature destroy of a transaction while a sending operation is on progress (the message is delivered, but the sent notification is delayed). This is similar to ticket #1646 problem no 2, just this case may occur when sending operation doesn't have transport yet and needs to resolve the server first. Also, it is unlikely to happen when the SIP endpoint has only one worker thread.

Scenario:

1. Thread A gets told by the resolver of addresses to send an INVITE to. INVITE is sent, sent notification callback send_msg_callback() is partially executed, context switch occurs right before acquiring transaction group lock.
2. Thread B receives an incoming 200 OK for the outbound INVITE. We send an ACK on this thread. The transaction for the outbound INVITE gets destroyed.
3. Thread A then attempts to acquire the group lock on the transaction, there is a crash because the transaction has already been destroyed by Thread B.

Notes to reproduce/simulate:

1. Send operation should be an async operation (not complete immediately) to make sure that tsx group lock is not being held when send_msg_callback() is called.
2. It needs at least two worker threads, e.g: run pjsua with "--thread-cnt 2" param, we need a worker thread to handle the incoming 200 OK and send ACK, while another worker thread handles the INVITE request sent notification.
3. Put sleep(~5 seconds) before acquiring tsx group lock in the send_msg_callback().

Thanks to Mark Michelson for the report.

[nanang]

In 5111:

Fixed #1859: Increment tsx group lock counter before send operation and decrement later in tsx's send_msg_callback() to avoid tsx premature destroy.