- according to clause 5.3.7.2 of 3GPP TS 38.331
  PDCP Suspend is not required during RRCReestablishment

- according to 5.3.7.4 of TS 38.331: 1> re-establish RLC for SRB1;
- gNB:
1) re-establish RLC for SRB1 in nr_rlc_update_id
2) re-establish RLC for remaining RBs concurrently with RRCReconfiguration

issue: gNB) in nr_rlc_update_id the gNB is re-establishing RLC for all
            RBs at the same time when receiving RRCReestablishmentRequest
            from UE
        UE) according to the specs, the UE is re-establishing RLC for
            SRB1 with RRCReestablishmentRequest the other RBs are
            re-established during RRCReconfiguration (in our case in
            nr_rrc_ue_process_RadioBearerConfig) when receiving
            reestablishRLC IE in rlc_BearerToAddModList
    RLC TX) this leads to RLC counters mismatch after re-establishment:
            control PDUs discarded until max nb of retx is reached
            and then UL failure occurs

- E1 encoding /decoding
- new enum for E1 Bearer Status Change

see 9.2.2.4 BEARER CONTEXT MODIFICATION REQUEST of 3GPP TS 38.463

- according to 5.3.7.4 of TS 38.331

- remove PDCP reestablishment for DRBs from RRCReestablishment message generation
- do PDCP reestablishment and CUUP notification calls after reception or RRCReestablishmentComplete
- this is necessary to make it consistent with the RRCReconfiguration message that contains
  RadioBearerConfig with the list of bearers to add/release
  which is followed by PDCP re-establishment at UE

- SRB1 shall be re-established at the time of RRCReestablishmentRequest
  according to 5.3.7.4 of 3GPP TS 38.331
- SRB2 shall be re-established when creating srb-ToAddModList
  according to 5.3.5.6.3 of 3GPP TS 38.331

Integration `2024.w14`

Closes #775 and #773

See merge request oai/openairinterface5g!2663

* !2411 Simple and generic trx_write support of out of time order requests
* !2532 moving decision on DCI format type to UE MAC
* !2565 improvements in security of nrUE
* !2656 remove stored G in UE DL, not needed and creating issues with DCI format 11/type0
* !2658 Fix sleeping ue at synchro
* !2649 NR SRS RRC assrtion removal
* !2662 Avoid concurrent write while filling RX/CRC.indication
* Remove obsolete "version" parameter from yaml files used on avra
* !2664 Remove duplicated NAS message send, already done above
* !2605 Improve performance polar encoder i.e., 3GPP 38.212 5.3.1.2 function
* !2629 Msg2 and Msg3 at gNB: check allocation before committing to Msg2
* !2657 replace transient malloc by stack allocation, add defense code on block size
* !2631 chore(ci): some docker improvements
* !2654 Pucch2 polar rx dynamic range fix
* !2666 [E2 Agent] Fix E2 Setup Request for ASan
* !2661 CI: iperf/iperf3 UDP analysis function fix → review in progress, review to be completed

Simplification of the code by replacing iperf_opt by target_bitrate (returned from Iperf_ComputeModifiedBW) - no need to repeat the steps to retrieve information about requested bitrate from iperf_opt. Compute iperf bitrate performance as receiver bitrate over requested (target) bitrate.
Fix an issue with misdetection of missing report line - "result" was defined 2x in the function. With this MR, result can be only None or stores output of re.search() for matching the report line pattern, which ensure proper detection of the report line as well as presence off all required components in the report line.

Sender bitrate is not always equal to the requested bitrate (set by "-b" iperf option) in iperf3 (v3.9) UDP tests, so we have to compture bitrate performance of UDP iperf3 test as receiver over requested bitrate. Bitrate performance then express percentage of requested bitrate, which is received on the receiver side.

For iperf3 (version 3.9) UDP, sender bitrate is not always equal to requested bitrate (defined by '-b' option). We need to retrieve information about the requsted bitrate from iperf command line options specified for each UDP testcase. This parameter is then used in UDP analysis functions for proper evaluation of the test results.

Prior to this commit, it might happen that the gNB used TDA 0 (Start 0
len 13) for mixed slot, in which case the UE could not send msg3
(because a mixed slot has less than 13 symbols).

fixes the overflow issue in the PUCCH2 RX with 4+ RX antennas and 12+
bits (polar code format). The fix scales the polar decoding LLR
computation according to the number of RX antennas. The issue was clear
for 100 MHz 4 RX antennas. Even

  nr_pucchsim -s -5 -q 8 -P 2 -b 12 -R 273 -z4 -n1000

doesn't converge to 0 BLER with increasing SNR. The issue didn't appear
in CI because of the bandwidth and antenna count limitations.

- docker on CI machine avra was updated to version 26.0.0, which reports
  parameter "version" as obsolete
- this additional log causes fail of the container undeployment to stage

: error: '<unknown>' may be used uninitialized [-Werror=maybe-uninitialized]
  180 |   reverse_bits_u8(tmp, N/8, D2);

Closes: #775

We observe these asserts while running concurrent UL traffic on many
UEs:

  Assertion (crc->rnti == rx->rnti) failed!
  In handle_nr_ulsch() ../../../openair2/NR_PHY_INTERFACE/NR_IF_Module.c:193
  mis-match between CRC RNTI 7221 and RX RNTI 35cf

CRC and RX indication need to be pairwise for one UE, when here we have
each for different UE. However, investigation seemed to indicate that
both arrays for CRC and RX indication contained only one PDU; it seemed
the RNTI changed while writing the CRC/RX.indication messages in
nr_fill_indication().

In this patch, we change the logic to mark a ULSCH free AFTER calling
nr_fill_indication(). It is difficult to say if this makes the assertion
disappear, but preliminary tests did not exhibit the same failure
states.

Closes #773

- It is only a couple of bytes
- It hid a bug: if two preambles, L1_nr_prach_procedures() overwrote the
  preamble of the first with the second one

if we reduce, we will never do all rach indications. Go one-by-one
instead.