When a message is received on the TURN socket, the code processing the
message needs to call into the ICE/STUN session for further processing.
This code path locks the TURN group lock then the ICE/STUN group lock.  In
another thread an ICE/STUN timer can fire off to send a keep alive message
over the TURN socket.  In this code path, the ICE/STUN group lock is
obtained then the TURN group lock is obtained to send the packet.  A
classic deadlock case if the group locks are not the same.

* Made TURN get created using the ICE/STUN session's group lock.

NOTE: I was originally concerned that the ICE/STUN session can get
recreated by ice_reset_session() for an event like RTCP multiplexing
causing a change during SDP negotiation.  In this case the TURN group lock
would become different.  However, TURN is also recreated as part of the
ICE/STUN recreation in ice_create() when all known ICE candidates are
added to the new ICE session.  While the ICE/STUN and TURN sessions are
being recreated there is a period where the group locks could be
different.

ASTERISK-27023 #close
Patches:
    res_rtp_asterisk-turn-deadlock-fix.patch (license #6502)
        patch uploaded by Michael Walton (modified)

Change-Id: Ic870edb99ce4988a8c8eb6e678ca7f19da1432b9