Changes

bts: TC_rsl_chan_initial_ta: misc improvements

Change-Id: Ifc2c850104b3710679485042ab5b7a758d0ae000
Related: OS#6919

bts: TC_rsl_chan_initial_ta: fix sporadic failures

It may happen that an UL SACCH block is received by the BTS before a DL
SACCH block is generated and delivered to the testcase.  In this case,
the Timing Advance control loop may update the initial TA value that
was set during RSL CHANnel ACTIVation.

By default, trxcon transmits UL SACCH blocks with TA=0, which is exactly
what triggers the TA control loop in this situation.

To avoid this, we explicitly signal the expected TA value to trxcon by
pre-populating the UL SACCH cache.  This is done by sending a DATA.req
containing a measurement report in advance, before establishing DCCH,
so that subsequent UL SACCH blocks carry the correct TA and do not
activate the control loop.

Additionally, take the opportunity to add missing f_L1CTL_PARAM().
This compensates for the artificial delay introduced by
f_trxc_fake_toffs256(), further reducing the risk of triggering
the TA control loop.

Change-Id: Iebb043ccc710750dff937e2281c23d343b85bda1
Related: OS#6919

bts: limit stderr logging to NOTICE to avoid long write() to ext4 fs

stderr being redirected to a file in the ext4 filesystem sometimes ends
up in write() syscall taking >500ms, which means the entire osmo-bts
process stalls during that time and we miss clock updates up to a
threshold which makes osmo-bts process exit with an error.

Let's decrease logging verbosity to NOTICE for now with the aim to not
run into those stalls during normal operation, while we can re-eanble
this manually when debugging the write() issue.

Related: OS#6794
Change-Id: I74c4abf7571d2a0f9ee22402a949dbde02896d7d