Add thread-checking to TransportFeedbackAdapter

webrtc/modules/congestion_controller/transport_feedback_adapter.h

Index: webrtc/modules/congestion_controller/transport_feedback_adapter.h
diff --git a/webrtc/modules/congestion_controller/transport_feedback_adapter.h b/webrtc/modules/congestion_controller/transport_feedback_adapter.h
index 704970611ce90b26e7b4378d1daf068b18108199..cc03cff0fbbefa0b6ca747a83217f1d348299bd9 100644
--- a/webrtc/modules/congestion_controller/transport_feedback_adapter.h
+++ b/webrtc/modules/congestion_controller/transport_feedback_adapter.h
@@ -73,6 +73,7 @@ class TransportFeedbackAdapter : public TransportFeedbackObserver,
   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