MSG3 scheduling data race.

MSG3 scheduling happens outside of dynamic_barrier that protects the UL scheduler from data races with the DL scheduler/decoding.

The typical way we handle this is that DCI indicates the RX-to-TX offset, and we set up the barrier accordingly. Later, once DL decoding is done, we join on the barrier, releasing the UL thread.

With RAR response, the DCI doesn't carry this information: The RX-to-TX value is known only after the MSG2 is decoded. This causes the UE to randomly "discard" the msg3 scheduling with a message like this:

2552.346478 [NR_MAC] E Error in ul config consistency, clearing it slot 19

It is not a big issue with normal CBRA; however, in the do-ra case with CFRA, the UE assumes the RAR decoding is successful and stops using the assigned preamble. The MSG3 is scheduled, but it is discarded because the UL scheduler for this slot has already run, and the test case fails.

This is the reason why the rfsim container_5g_rfsim_tdd_dora.xml testcase fails so often.