Callback for send bitrate estimates - new roll

Issue https://webrtc-codereview.appspot.com/4459004/ was commited as
r5259, after which flakiness was detected and a rollback was performed
at r5261.

Patch Set 1 of this issue is the code submitted in r5259. Subsequent
patch sets fixes a race condition which caused the seen problems.

The root cause was a dead lock between a thread sending rtp packets and
and a timed module processing thread:

webrtc::RTPSender::BitrateUpdated()  // Get RTPSender stats lock
webrtc::Bitrate::Process()  // Get Bitrate lock
webrtc::RTPSender::ProcessBitrate()
webrtc::ModuleRtpRtcpImpl::Process()
...

webrtc::Bitrate::Update()  // Get Bitrate lock
webrtc::RTPSender::UpdateRtpStats()  // Get RTPSender stats lock
webrtc::RTPSender::SendToNetwork()
...

This is fixed in Bitrate::Process() by releasing the lock before
calling the callback.

BUG=2235
R=mflodman@webrtc.org

Review URL: https://webrtc-codereview.appspot.com/5619004

git-svn-id: http://webrtc.googlecode.com/svn/trunk@5281 4adac7df-926f-26a2-2b94-8c16560cd09d

webrtc/modules/rtp_rtcp/source/receive_statistics_impl.cc

@@ -27,7 +27,7 @@ StreamStatistician::~StreamStatistician() {}
 StreamStatisticianImpl::StreamStatisticianImpl(Clock* clock)
     : clock_(clock),
       crit_sect_(CriticalSectionWrapper::CreateCriticalSection()),
-      incoming_bitrate_(clock),
+      incoming_bitrate_(clock, NULL),
       ssrc_(0),
       max_reordering_threshold_(kDefaultMaxReorderingThreshold),
       jitter_q4_(0),