It is highly unlikely to happen but if so, we need to know and why. The
warning with the next_run values could help.

Signed-off-by: David Goulet <dgoulet@torproject.org>

When the KIST schedule() is called, it computes a diff value between the last
scheduler run and the current monotonic time. If tha value is below the run
interval, the libevent even is updated else the event is run.

It turned out that casting to int32_t the returned int64_t value for the very
first scheduler run (which is set to 0) was creating an overflow on the 32 bit
value leading to adding the event with a gigantic usec value. The scheduler
was simply never running for a while.

First of all, a BUG() is added for a diff value < 0 because if the time is
really monotonic, we should never have a now time that is lower than the last
scheduler run time. And we will try to recover with a diff value to 0.

Second, the diff value is changed to int64_t so we avoid this "bootstrap
overflow" and future casting overflow problems.

Fixes #23558

Signed-off-by: David Goulet <dgoulet@torproject.org>

This is an "ours" merge to avoid the conflict from the 0.2.8 version
of the fix for TROVE-2017-008.

Fixes bug 23490; bugfix on 0.2.7.2-alpha.

TROVE-2017-008
CVE-2017-0380

Fixes bug 23490; bugfix on 0.2.7.2-alpha.

TROVE-2017-008
CVE-2017-0380

This was introduced in 4ff170d7, and is probably
unreachable, but coverity complained about it (CID 1417761). Bug not
in any released Tor, so no changes file.

So, remove it.

I don't know where these came from.

Resolve conflict with 23532 code.

Otherwise integer overflows can happen.  Remember, doing a i32xi32
multiply doesn't actually produce a 64-bit output.  You need to do
i64xi32 or i64xi64.

Coverity found this as CID 1417753

Catalyst points out that using pw_uid for two different purposes
here is likely to be confusing.