stasis transfer: fix stasis bridge push race part two

When swapping a Local channel in place of one already
in a bridge (to complete a bridge attended transfer),
the channel that was swapped out can actually be hung
up before the stasis bridge push callback executes on
the independant transfer thread.  This results in the
stasis app loop dropping out and removing the control
that has the the app name which the local replacement
channel needs so it can re-enter stasis.

To avoid this race condition a new push_peek callback
has been added, and called from the ast_bridge_impart
thread before it launches the independant thread that
will complete the transfer.  Now the stasis push_peek
callback can copy the stasis app name before the swap
channel can hang up.

ASTERISK-24649
Review: https://reviewboard.asterisk.org/r/4382/
........

Merged revisions 431450 from http://svn.asterisk.org/svn/asterisk/branches/13


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431451 65c4cc65-6c06-0410-ace0-fbb531ad65f3

include/asterisk/bridge.h

@@ -241,6 +241,8 @@ struct ast_bridge_methods {
 	ast_bridge_notify_masquerade_fn notify_masquerade;
 	/*! Get the bridge merge priority. */
 	ast_bridge_merge_priority_fn get_merge_priority;
+	/*! Peek at swap channel before it can hang up, prior to push. */
+	ast_bridge_push_channel_fn push_peek;
 };
 
 /*! Softmix technology parameters. */