commit bb7ee95c7184ced730c7e6885e87229cdd671f7a
author Victor Boivie <boivie@webrtc.org> Wed May 05 10:36:52 2021
committer WebRTC LUCI CQ <webrtc-scoped@luci-project-accounts.iam.gserviceaccount.com> Wed May 05 13:13:03 2021
tree 33b42c611a1b3109330e5405a7ec80eee56d0462
parent 1d2fa9a1c3a6c481e2d8c6937a4f77cb83ae4716

dcsctp: Handle starting timer from timer callback

This was caught in an integration test which had stricter assertions
than the FakeTimeout which is used in unit tests, so the first thing was
to add the same assertions to the FakeTimeout.

The issue is that when a Timer triggers, and if it's set to
automatically restart (possibly with an exponential backoff), the
`is_running_` field was set to true while the timer callback was called
to allow the client to know that the timer is in fact running, but the
timer was actually not started until the callback returned. Which made
sense, as the callback can with its return value override the duration,
which should affect the backoff algorithm.

The problem was when a timer was manually started within the callback.
As the Timer itself thought that it was already running, it first would
Stop() the underlying Timeout, then Start(). But calling Stop() on a
timeout that is not running is illegal, which set of assertions.

So the solution is to don't lie; Don't say that a timer is running when
it's not. Make sure that the timer is running when the timer callback is
triggered, which makes it consistent at all times. That may result in
unnecessary timeout invocations (stopping and starting), but that's not
too expensive.

Bug: webrtc:12614
Change-Id: I7b4447ccd88bd43d181e158f0d29b0770c8a3fd6
Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/217522
Reviewed-by: Florent Castelli <orphis@webrtc.org>
Commit-Queue: Victor Boivie <boivie@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#33926}