Fix a crash that would occur when receiving a 491 response to a reinvite.

The reviewboard description does a fine job of summarizing this, so here it is:

A reporter discovered that Asterisk would crash when attempting to retransmit
a reinvite that had previously received a 491 response. The crash occurred
because a pjsip_tx_data structure was being saved for reuse, but its reference
count was not being increased. The result was that the pjsip_tx_data was being
freed before we were actually done with it. When we attempted to re-use the
structure when re-sending the reinvite, Asterisk would crash.

The fix implemented here is not to try holding onto the pjsip_tx_data at all.
Instead, when we reschedule sending the reinvite, we create a brand new
pjsip_tx_data and send that instead. Because of this change, there is no need
for an ast_sip_session_delayed_request structure to have a pjsip_tx_data on
it any more. So any code referencing its use has been removed.

When this initial fix was introduced, I encountered a second crash when
processing a subsequent 200 OK on a rescheduled reinvite. The reason was
that when rescheduling the reinvite, we gave the wrong location for a
response callback. This has been fixed in this patch as well.

ASTERISK-24556 #close
Reported by Abhay Gupta

Review: https://reviewboard.asterisk.org/r/4233



git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/13@429089 f38db490-d61c-443f-a65b-d21fe96a405b
AMI/ARI: Update version to 2.6.0/1.6.0 respectively for new features

AMI/ARI are getting a few enhancements in the next release of Asterisk 13. Per
semantic versioning, that warrants a bump in the minor version number, as it
reflects a backwards compatible change. Hence, this commit.


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/13@429091 f38db490-d61c-443f-a65b-d21fe96a405b