Add a 'secret' probation strictrtp mode to handle delayed changes in RTP source

Often, Asterisk may realize that a change in the source of an RTP stream is
about to occur and ask that the RTP engine reset it's lock on the current RTP
source. In certain scenarios, it may take awhile for the new remote system to
send RTP packets, while the old remote system may continue providing RTP during
that time period. This causes Asterisk to re-lock onto the old source, thereby
rejecting the new source when the old source stops sending RTP and the new
source begins.

This patch prevents that by having a constant secondary, 'secret' probation
mode enabled when an RTP source has been chosen. RTP packets from other sources
are always considered, but never chosen unless the current RTP source stops
sending RTP.

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

(closes issue AST-1124)
Reported by: John Bigelow
Tested by: John Bigelow

(closes issue AST-1125)
Reported by: John Bigelow
Tested by: John Bigelow



git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/11@382573 f38db490-d61c-443f-a65b-d21fe96a405b
Ensure that logmsgs are freed properly

Messages sent while the logger thread is shutting down will now have
their associated callid freed properly.


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