Changes

trx_toolkit/clck_gen: Fix clock generator to emit ticks with exactly GSM frame period

Since fake_trx beginning in 3187c8e6 (target/fake_trx: initial release
of virtual transceiver) CLCKGen was tuned to emitting ticks with sleep
period being time of 1 GSM frame _decreased_ a bit by "Average loop back
delay". The idea for this decrease probably was to compensate the time
spent in each tick handler, so that combined sleep + tick work would
occupy time of 1 GSM frame more or less.

The idea of using hardcoded compensation turned out to be not very good,
because for the overall tick period to be exactly as defined the
compensation should be dynamic and take into account time spent in each
tick handler. For example on one machine "loopback delay" is one value,
while on another it will be another value. And if we attach more work to
tick handler, like it already happened with adding tx queue, the
compensation needs to take all that into account as well.

abc63d8d (trx_toolkit/clck_gen.py: Fix clock generator not to accumulate
timing error) explains the problem in detail and adds dynamic
compensation so that the tick period stays as defined instead of
drifting. But it missed to adjust CLCKgen to stop decreasing desired
tick period a bit by "average loop back delay".

So after that patch, because CLCKgen now follows desired period without
drifting, its period was 4.615ms - 0.09ms instead of exact 4.615ms,
which resulted in e.g. fake_trx and bts-trx clocks to become constantly
dissynchronized with the following emitted by bts-trx non-stop:

    20250122135431420 <0006> scheduler_trx.c:576 GSM clock skew: old fn=0, new fn=102
    20250122135431882 <0006> scheduler_trx.c:604 We were 3 FN slower than TRX, compensated
    20250122135432344 <0006> scheduler_trx.c:604 We were 2 FN slower than TRX, compensated
    20250122135432805 <0006> scheduler_trx.c:604 We were 2 FN slower than TRX, compensated
    20250122135433267 <0006> scheduler_trx.c:604 We were 2 FN slower than TRX, compensated
    20250122135433728 <0006> scheduler_trx.c:604 We were 2 FN slower than TRX, compensated
    20250122135434190 <0006> scheduler_trx.c:604 We were 2 FN slower than TRX, compensated
    20250122135434651 <0006> scheduler_trx.c:604 We were 2 FN slower than TRX, compensated
    20250122135435113 <0006> scheduler_trx.c:604 We were 2 FN slower than TRX, compensated
    20250122135435575 <0006> scheduler_trx.c:604 We were 2 FN slower than TRX, compensated
    20250122135436036 <0006> scheduler_trx.c:604 We were 2 FN slower than TRX, compensated
    20250122135436498 <0006> scheduler_trx.c:604 We were 2 FN slower than TRX, compensated
    20250122135436959 <0006> scheduler_trx.c:604 We were 2 FN slower than TRX, compensated
    20250122135437421 <0006> scheduler_trx.c:604 We were 2 FN slower than TRX, compensated
    ...

What happens here is that there are ~ 216 GSM frames every second, and
since fake_trx drifts by 0.09ms every frame, it results in drifting by ~
20ms every second. Which results in "2 FN slower than TRX" emitted
approximately twice per second as above log excerpt confirms.

-> Fix this by adjusting CLCKgen to emit ticks with exactly GSM frame
period by default.

Change-Id: Ie12fbe8138bac1398805fa270b869e7a333fcba0