Various fixes for DNS IPv6

[ming]

1. There is a race condition introduced with the IPv6 DNS patch.
   Given
   *) Thread A sending a SIP request that needs DNS resolution.
   *) Thread B handling DNS query responses in pjsip_endpt_handle_events().
   The call to pjsip_resolve() happens under Thread A which sets a dummy query:

   query->object6 = (pj_dns_async_query*)0x1;
   

   and then calls pj_dns_resolver_start_query() with the dns_a_callback().
   However, the dummy query protection is undone because the first thing that pj_dns_resolver_start_query() with the dns_a_callback() does is to set query->object6 to NULL when it is called.
   Then in thread B, the dns_a_callback() sees that there isn't an IPv6 query and attempts to send the request immediately even if there may not be any A records in the response. The pending dns_aaaa_callback() can now attempt to use resources that may be destroyed.

2. In pjsip_resolve() the pj_dns_resolver_start_query() for the AAAA records should be guarded by a status == PJ_SUCCESS check in case the A records query start fails.

3. In both dns_a_callback() & dns_aaaa_callback():
   

   if (srv->count > 0)
      (*query->cb)(PJ_SUCCESS, query->token, &query->server);
   else
      (*query->cb)(query->last_error, query->token, NULL);
   

   However, query->last_error is never set, thus in sip_util.c stateless_send_resolver_callback() it will hit the assertion:

   pj_assert(tdata->dest_info.addr.count != 0);
   

   If assertion in disabled, later in stateless_send_transport_cb() the code line:

   cont = (sent > 0) ? PJ_FALSE :
   (tdata->dest_info.cur_addr<tdata->dest_info.addr.count-1);
   

   can result in an underflow.

4. Fixed bug of premature app callback invocation for SRV resolver by applying the same method in r5369.

Thank you to Richard Mudgett (Digium) for the report.

[ming]

In 5471:

Fixed #1974: Various fixes for DNS IPv6