Handle IP change scenario for calls that are not yet confirmed (draft)

[sauwming]

Handle IP change scenario for calls that are not yet on confirmed state.

The PR is still in draft stage.

List of changes in the patch:

• send UPDATE when calls are not yet confirmed
  And we will automatically use UPDATE for those calls, because otherwise app will be forced to set reinv_use_update to PJ_TRUE, which may not be desirable if it still prefers to use reinvite for established calls.
• Prevent transaction from being terminated and calls from getting disconnected when keep_inv_after_tsx_timeout, which is automatically enabled when IP change is initiated, is set to PJ_TRUE. Do we need to create a separate setting for this?
• Update pjsua sample app to output the log that the IP change is in progress, instead of succeeded, which gave the impression that the process has completed.

What still doesn't work:

• Even though the UPDATE has been successfully sent, the remote still wrongly sent the response to the old address. There are a couple of things that needs to be fixed:
  a. pjsip_inv_answer() will use pjsip_tx_data_clone() of the last answer.
  b. sending 487 after call being cancelled also uses inv->invite_tsx->last_tx.
  Attempt to fix a) is in progress, by replacing the Via with the ones from the last incoming UPDATE. But this still doesn't work because transaction lookup will later fail due to the Via branch change. An idea to solve this is by keeping the branch param when updating the Via. Not sure if this is feasible, but the RFC doesn't seem to prohibit this.
• Sending UPDATE will fail if SDP negotiation hasn't completed. Should we send the UPDATE without SDP instead for such cases?

TODO:
update wiki

[trengginas]

Made some modifications:

• Add check keep_inv_after_tsx_timeout applied to INVITE message.
• Remove reverting keep_inv_after_tsx_timeout when IP change progress is completed.
  • The tsx will be terminated because the flag keep_inv_after_tsx_timeout has been reverted once the event (transport error) was sent to transaction layer.

Notes:
It's simple to test on windows.

• Use TCP/TLS transport to as SIP transport
• Change wifi/network access, the transport error will be raised and on_transport_state is called. Afterwards, call pjsua_handle_ip_change(). This is not the case on other platforms(e.g: linux, mac). The transport error is not triggered.
• UPDATE request/respons were sent/received correctly.