time.time() can go backwards

[totaam]

A number of places assume that this is never the case.
This can cause problems when ntp adjusts the time.

[totaam]

Monotonic time is implemented in python 3.3 and later: time.monotonic and
CLOCK_MONOTONIC.

For python2, we can use ctypes: [http://stackoverflow.com/a/1205762/428751] but the problem here is performance:

import timeit
from time import time
from xpra.os_util import monotonic_time
timeit.timeit(monotonic_time, number=1000000)
1.3700509071350098
timeit.timeit(time, number=1000000)
0.04274415969848633

So using ctypes is 33 times slower than calling "time"!
And osx doesn't have a librt, win32 doesn't have support for monotonic clocks at all?

[totaam]

• r15365 converts almost all time.time() calls to a os_util wrapper named monotonic_time (defaults to still use time.time())
• r15366 + r15367 converts it to using a cythonized version, which is just as fast and actually monotonic

For win32 we would need to call GetTickCount64 and translate that into a time value... from a starting reference point ourselves. This would allow us to cimport the function from all the cython modules, saving conversion to a python type and back.

This will do. Tested on both Linux and macosx.

[totaam]

r15368 (+r15369 fixup) does implement it for win32 so we can cimport the function from all the cython modules.

[totaam]

r15376 fixes the RPM packaging.

[totaam]

Similar fix applied to the Javascript code in r16441.

[totaam]

Caused a bug: #2038

[totaam]

Switched back to the standard library in 1f270b9