ConfBridge: Rework announcer channel methodology

NOTE: This patch was submitted earlier and reverted because of a failing
test. The test has been patched so that it adjusts for the changes here,
so this is being resubmitted for review.

One feature that confbridge has is the ability to play sounds to all
participants in the conference. Prior to this commit, the algorithm for
this was as follows:

* Grab the playback lock
* Push the conference announcer channel into the bridge
* Play back the sound
* Pull the conference announcer channel from the bridge
* Release the playback lock

The issue here is that the act of adding the playback channel to the
bridge and removing it for each announcement is expensive. Amongst the
expenses:

* The announcer channel is imparted into the bridge, meaning a new
  thread is spun up for each playback.
* When the announcer is added or removed from the bridge, it results
  in the BRIDGEPEER channel variable being set on all channels in the
  bridge. This requires keeping the bridge locked and locking each
  individual channel in order to set it.
* There's also just the general overhead of adding the channel and
  removing it from the bridge. The bridge potentially has to reconfigure
  every single time

With this commit, the paradigm for playing back announcements has
shifted.

* The announcer channel is now added to the bridge when the conference
  is allocated, and it is hung up when the conference is destroyed.
* A taskprocessor is used to queue playbacks onto the announcer channel.
  This keeps the behavior from before where playbacks do not overlap.
* The announcer channel is no longer placed into the bridge as
  departable. Since we are not constantly removing the channel from
  the bridge, it is safe to add the channel using an independent thread
  and simply hang the channel up when it is time for the conference to
  be destroyed.

The use of the taskprocessor for playbacks opens up the interesting
possibility of having asynchronous announcements played. In this commit,
however, the behavior is still exactly the same as it previously was.

ASTERISK-26289
Reported by Mark Michelson

Change-Id: Ica9fa4907c2f3728cdd1cf0bc564ef4eb40754a0

0 files changed, 0 insertions, 0 deletions