Revert of Improving the fake clock and using it to fix a flaky STUN timeout test.

Revert of Improving the fake clock and using it to fix a flaky STUN timeout test. (patchset #10 id:180001 of https://codereview.webrtc.org/2024813004/ )

Reason for revert:
There seems to be a TSan warning that wasn't caught by the trybot: https://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan%20v2/builds/6732/steps/peerconnection_unittests/logs/stdio

Apparently a thread is still alive even after destroying WebRTCSession. Need to think of a way to fix this, without adding a critical section around g_clock (since that would hurt performance).

Original issue's description:
> Improving the fake clock and using it to fix a flaky STUN timeout test.
>
> When the fake clock's time is advanced, it now ensures all pending
> queued messages have been dispatched. This allows us to write a
> "SIMULATED_WAIT" macro that ticks the simulated clock by milliseconds up
> until the target time.
>
> Useful in this case, where we know the STUN timeout should take a total
> of 9500ms, but it would be overly complex to write test code that waits
> for each individual timeout, ensures a STUN packet has been
> retransmited, etc.
>
> (The test described above *should* be written, but it belongs in
> p2ptransportchannel_unittest.cc, not webrtcsession_unittest.cc).
>
> Committed: https://crrev.com/ffbe0e17e2c9b7fe101023acf40574dc0c95631a
> Cr-Commit-Position: refs/heads/master@{#13043}

TBR=pthatcher@webrtc.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Committed: https://crrev.com/f83a94a41e82c27b01166d590a422ca63a0a7bca
Cr-Commit-Position: refs/heads/master@{#13045}

[Taylor Brandstetter, 2016-06-03 23:05:14]

The CQ bit was checked by deadbeef@webrtc.org

[Taylor Brandstetter, 2016-06-03 23:05:14]

Created Revert of Improving the fake clock and using it to fix a flaky STUN
timeout test.

[commit-bot: I haz the power, 2016-06-03 23:05:19]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/2038213002/1

[commit-bot: I haz the power, 2016-06-03 23:05:29]

Description was changed from

==========
Revert of Improving the fake clock and using it to fix a flaky STUN timeout
test. (patchset #10 id:180001 of https://codereview.webrtc.org/2024813004/ )

Reason for revert:
There seems to be a TSan warning that wasn't caught by the trybot:
https://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan%20v2/builds/...

Apparently a thread is still alive even after destroying WebRTCSession. Need to
think of a way to fix this, without adding a critical section around g_clock
(since that would hurt performance).

Original issue's description:
> Improving the fake clock and using it to fix a flaky STUN timeout test.
> 
> When the fake clock's time is advanced, it now ensures all pending
> queued messages have been dispatched. This allows us to write a
> "SIMULATED_WAIT" macro that ticks the simulated clock by milliseconds up
> until the target time.
> 
> Useful in this case, where we know the STUN timeout should take a total
> of 9500ms, but it would be overly complex to write test code that waits
> for each individual timeout, ensures a STUN packet has been
> retransmited, etc.
> 
> (The test described above *should* be written, but it belongs in
> p2ptransportchannel_unittest.cc, not webrtcsession_unittest.cc).
> 
> Committed: https://crrev.com/ffbe0e17e2c9b7fe101023acf40574dc0c95631a
> Cr-Commit-Position: refs/heads/master@{#13043}

TBR=pthatcher@webrtc.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
==========

to

==========
Revert of Improving the fake clock and using it to fix a flaky STUN timeout
test. (patchset #10 id:180001 of https://codereview.webrtc.org/2024813004/ )

Reason for revert:
There seems to be a TSan warning that wasn't caught by the trybot:
https://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan%20v2/builds/...

Apparently a thread is still alive even after destroying WebRTCSession. Need to
think of a way to fix this, without adding a critical section around g_clock
(since that would hurt performance).

Original issue's description:
> Improving the fake clock and using it to fix a flaky STUN timeout test.
> 
> When the fake clock's time is advanced, it now ensures all pending
> queued messages have been dispatched. This allows us to write a
> "SIMULATED_WAIT" macro that ticks the simulated clock by milliseconds up
> until the target time.
> 
> Useful in this case, where we know the STUN timeout should take a total
> of 9500ms, but it would be overly complex to write test code that waits
> for each individual timeout, ensures a STUN packet has been
> retransmited, etc.
> 
> (The test described above *should* be written, but it belongs in
> p2ptransportchannel_unittest.cc, not webrtcsession_unittest.cc).
> 
> Committed: https://crrev.com/ffbe0e17e2c9b7fe101023acf40574dc0c95631a
> Cr-Commit-Position: refs/heads/master@{#13043}

TBR=pthatcher@webrtc.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
==========

[commit-bot: I haz the power, 2016-06-03 23:05:30]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-06-03 23:05:33]

Description was changed from

==========
Revert of Improving the fake clock and using it to fix a flaky STUN timeout
test. (patchset #10 id:180001 of https://codereview.webrtc.org/2024813004/ )

Reason for revert:
There seems to be a TSan warning that wasn't caught by the trybot:
https://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan%20v2/builds/...

Apparently a thread is still alive even after destroying WebRTCSession. Need to
think of a way to fix this, without adding a critical section around g_clock
(since that would hurt performance).

Original issue's description:
> Improving the fake clock and using it to fix a flaky STUN timeout test.
> 
> When the fake clock's time is advanced, it now ensures all pending
> queued messages have been dispatched. This allows us to write a
> "SIMULATED_WAIT" macro that ticks the simulated clock by milliseconds up
> until the target time.
> 
> Useful in this case, where we know the STUN timeout should take a total
> of 9500ms, but it would be overly complex to write test code that waits
> for each individual timeout, ensures a STUN packet has been
> retransmited, etc.
> 
> (The test described above *should* be written, but it belongs in
> p2ptransportchannel_unittest.cc, not webrtcsession_unittest.cc).
> 
> Committed: https://crrev.com/ffbe0e17e2c9b7fe101023acf40574dc0c95631a
> Cr-Commit-Position: refs/heads/master@{#13043}

TBR=pthatcher@webrtc.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
==========

to

==========
Revert of Improving the fake clock and using it to fix a flaky STUN timeout
test. (patchset #10 id:180001 of https://codereview.webrtc.org/2024813004/ )

Reason for revert:
There seems to be a TSan warning that wasn't caught by the trybot:
https://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan%20v2/builds/...

Apparently a thread is still alive even after destroying WebRTCSession. Need to
think of a way to fix this, without adding a critical section around g_clock
(since that would hurt performance).

Original issue's description:
> Improving the fake clock and using it to fix a flaky STUN timeout test.
>
> When the fake clock's time is advanced, it now ensures all pending
> queued messages have been dispatched. This allows us to write a
> "SIMULATED_WAIT" macro that ticks the simulated clock by milliseconds up
> until the target time.
>
> Useful in this case, where we know the STUN timeout should take a total
> of 9500ms, but it would be overly complex to write test code that waits
> for each individual timeout, ensures a STUN packet has been
> retransmited, etc.
>
> (The test described above *should* be written, but it belongs in
> p2ptransportchannel_unittest.cc, not webrtcsession_unittest.cc).
>
> Committed: https://crrev.com/ffbe0e17e2c9b7fe101023acf40574dc0c95631a
> Cr-Commit-Position: refs/heads/master@{#13043}

TBR=pthatcher@webrtc.org,tommi@webrtc.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Committed: https://crrev.com/f83a94a41e82c27b01166d590a422ca63a0a7bca
Cr-Commit-Position: refs/heads/master@{#13045}
==========

[commit-bot: I haz the power, 2016-06-03 23:05:34]

Patchset 1 (id:??) landed as
https://crrev.com/f83a94a41e82c27b01166d590a422ca63a0a7bca
Cr-Commit-Position: refs/heads/master@{#13045}