Add thread-checking to TransportFeedbackAdapter

webrtc/modules/congestion_controller/transport_feedback_adapter.h

 /*
  *  Copyright (c) 2015 The WebRTC project authors. All Rights Reserved.
  *
  *  Use of this source code is governed by a BSD-style license
  *  that can be found in the LICENSE file in the root of the source
  *  tree. An additional intellectual property rights grant can be found
  *  in the file PATENTS.  All contributing project authors may
  *  be found in the AUTHORS file in the root of the source tree.
  */
 
@@ skipping 55 matching lines @@
   rtc::CriticalSection bwe_lock_;
   int transport_overhead_bytes_per_packet_ GUARDED_BY(&lock_);
   SendTimeHistory send_time_history_ GUARDED_BY(&lock_);
   std::unique_ptr<DelayBasedBwe> delay_based_bwe_ GUARDED_BY(&bwe_lock_);
   RtcEventLog* const event_log_;
   Clock* const clock_;
   int64_t current_offset_ms_;
   int64_t last_timestamp_us_;
   BitrateController* const bitrate_controller_;
   std::vector<PacketInfo> last_packet_feedback_vector_;
+  rtc::ThreadChecker last_packet_feedback_vector_thread_checker_;

[minyue-webrtc, 2017/02/23 14:45:51]

one cannot bind a thread checker to a data.  Rather, it is to check whether a 
method is called on a correct thread. therefore, it is a bit awkward to call
this last_packet_feedback_vector_thread_checker_.

So I think it would be better to call this feedback_access_thread_checker_ or
similar.

But I like a lock even more.

[elad.alon_webrtc.org, 2017/02/23 14:52:00]

1. I'm introducing checkers now to all of the functions, as per the last
comment. They'll be named after their threads' function, not after the data they
protect.
2. Stefan preferred a thread checker. Either decision seems okay to me in
principle, but I prefer the checker, since I see no reason to incur the cost of
a lock when we only ever touch this from one thread.

 };
 
 }  // namespace webrtc
 
 #endif  // WEBRTC_MODULES_CONGESTION_CONTROLLER_TRANSPORT_FEEDBACK_ADAPTER_H_