app_queue currently attempts to handle Local channel optimizations in an effort
to provide accurate information in Stasis messages (and their corresponding
AMI events) as well as the Queue log. Sometimes, however, things don't go as
planned.

Consider the following scenario:
 SIP/foo <-> L;1 <-> L;2 <-> SIP/agent

SIP/agent answers, triggering a Local channel optimization. app_queue will
normally do the following:
 * Listen for the Local optimization events and update our agent accordingly
   to SIP/agent in the queue log and messages
 * When we get a hangup, publish the AgentComplete event based on our
   information (SIP/foo and SIP/agent)

However, as with all things that depend on sanity from something as capricious
as Local channels, things can go wrong:
 (1) SIP/agent immediately hangs up upon answering. This triggers a race
     condition between termination messages coming from SIP/agent and the
     ongoing Local channel optimization messages. (Note that this can also
     occur with SIP/foo)
 (2) In a race condition, Asterisk can (rarely) deliver the hangup messages
     prior to the Local channel optimization.

In that case, the messages *may* arrive to app_queue in the following order:
 * Hangup SIP/Agent
 * Hangup SIP/foo
 * Optimize L;1/L;2
 * Hangup L;2
 * Hangup L;1

When app_queue receives the hangup of the agent or the caller, it will attempt
to publish the AgentComplete event. However, it now has a problem - it thinks
its agent is the ;1 side of the Local channel, as it never received the
optimization event. At the same time, that channel is already gone. This
results in getting NULL from the Stasis cache. What's more, we can't really
wait for the optimization message, as we are currently handling the hangup
of the channel that the optimization event would tell us to use.

This patch modifies the behavior in app_queue such that, since we still have a
lot of pertinent queue information (interface, queue name, etc.), we now raise
the event with what information we know. The channels involved now may or may
not be present. Users will still at least get the "AgentComplete" event, which
"completes" the known Agent information.

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

(closes issue ASTERISK-22507)
Reported by: Richard Mudgett
........

Merged revisions 400060 from http://svn.asterisk.org/svn/asterisk/branches/12


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