Report disconnection event immediately when hanging up a call

[sauwming]

To continue the work in #1049 and close it.

• When calling pjsua_call_hangup(), application will immediately receive on_call_state() callback with DISCONNECTED state. No further call related callbacks will be received after this. The call hangup process itself (sending BYE, waiting for the response, and resource cleanup) will continue in the background and the call slot can be reused only after this process is completed.
• Retry creating and sending BYE after a period of CALL_HANGUP_RETRY_INTERVAL if it fails. If this keeps happening after CALL_HANGUP_MAX_RETRY times, we will hard-terminate the call, i.e. cleanup the call without sending any BYE to the remote.

This will introduce some behavioural changes though:

• Since call disconnection state is now expected to be the last call-related callback, media will be deinitialised immediately upon hanging up, before disconnected state is reported. So media callbacks such as on_stream_destroyed() will be called before on_call_state(). Previously, it was the reverse.
• Application can no longer dump end-of-call media stats upon receiving disconnection report. This is because media has been deactivated by then. One alternative is to dump media stats in on_stream_destroyed(), but note that on_stream_destroyed() can also be called during media update, can be called multiple times if there are more than one audio streams, and won't be called if there is no audio (such as in video-only calls).

[nanangizz]

Just recalled about the idea of adding an API to get info about free call slot count. But then perhaps it can be calculated from pjsua_call_get_max_count()-pjsua_call_get_count(), so I guess it is not necessary? Or perhaps we should add info about it in the pjsua_call_hangup() docs.

[sauwming]

Comment from @calanor in #2582

About calling pjsua_call_dump() in on_stream_destroyed().
With this change, if we receive the hang up, the call_dump appears as "DISCONNCTD", but if we are the ones who hang up the call, it appears as "CONFIRMED".
Before, in on_call_state, in all cases the call dump appears as "DISCONNCTD".

Yes, that's true. I was thinking of introducing a flag to detect this, but was not sure if it's necessary or if it's going to be useful. Let us know if this causes any complications.

[calanor]

No, it is not a problem for me. I was just saying it for your information.

[IvanOgloblin]

I am developing a sip application for Android. Faced such a situation:
I am starting to display preview and incoming video. At the same time, I am receiving BYE from the other side.
It turns out at the same time I start the video and try to finish it. The library at this moment freezes the codec: Encoder dequeueInputBuffer failed [-1]. Hang occurs in pjsua_vid_stop_stream(...) when unsubscribed from all events.
I would like to know how to immediately get a callback when a BYE is received, so as not to start trying to preview or incoming video display.

Regards, Ivan.