Bug report: `maxslewrate` violation by chrony

Hi folks,

I wanted to report a bug. We use chrony for time synchronization and we
have a strict requirement that forces us to limit the slew rate to no more
than 250ppm. We noticed that in some conditions, chrony exceeds this limit
by >10x. I've collected an strace that shows chrony is indeed the culprit
as it is calling the clock_adjtime syscall with the tick and frequency set
to 9980 and -140765 which corresponds to roughly -2002ppm.

This bug shows up relatively infrequently under "normal" conditions, but I
built a command line tool (https://github.com/brt-adam-snaider/wreck_time)
that continuously modifies the CLOCK_REALTIME with different parameters and
found that a semi-consistent number of times, running it with the following
configuration for around 30 minutes results in the aforementioned bug in
our system (your mileage may vary).

$ sudo ./wreck_time random --frequency 2 --low 100ns --high 10ms

The relevant bits of configuration are
maxslewrate 250
makestep 500 -1 # Different for testing. Generally we have `makestep 0.004
-1`
maxclockerror 10

OS: Linux
Chrony version: Tested on 3.5 and 4.3

~Adam