This time constant plays a major role in how long a UE has to wait
maximally before it might be scheduled. For instance, if a UE had a lot
of traffic, the average traffic will be high, pushing the PF coefficient
down. If another UE with no traffic in the past becomes active with
heavy traffic, the first UE might not be scheduled for an extended
period of time.

In the AW2S-Amarisoft UE CI test pipeline, we sometimes see that the
maximum number of RLC retransmissions was reached. While this might not
be the (only) cause, scheduling a UE more often might prevent such
situations, and we saw an improved stability.

Merge remote-tracking branch 'origin/remove-rw-globals-that-are-not-written' into integration_2023_w33

- Global variables that are never written to are marked const
- Remove some EXTERN declaration
- Remove unused `log_mem_multi` from logging module

Merge remote-tracking branch 'origin/avoid_NR_UE_stall_if_SIB1_not_decoded' into integration_2023_w33

Merge remote-tracking branch 'origin/negativeIndex_cppcheck_fix_on_w27_2023' into integration_2023_w33

Merge remote-tracking branch 'origin/nullPointerArithmeticRedundantCheck_cppcheck_fix_on_w27_2023' into integration_2023_w33

When t_poll_retransmit expires we need to consider an SDU for
retransmission.

We used to take the first SDU (which could be a segment, not a full SDU)
of the wait list and put it in the retransmit list.

When testing with some UE (Amarisoft UE) a bad behavior was detected.

This is what happens for the SDU with SN 6 (for illustration purpose).

The gNB is sending an SDU in several pieces (it is segmented).

slot n:     rlc sn 6 [1 .. 119[   p=0   RECEIVED
slot n+x:   rlc sn 6 ]120 .. 180[ p=0   RECEIVED
slot n+x+y: rlc sn 6 ]181 .. 210] p=1   not RECEIVED

Then when t_poll_retransmit expires rlc retransmits only the PDU of
slot n (with p=1 this time) and the UE replies with ack 6. So nothing
happens on the gnb side.
(We would have expected ack 7 + nack 6 181..end.)

Then after t_poll_retransmit expires again rlc retransmits only PDU
of slot n and the UE still replies with ack 6.

This goes on forever (or some other timeout occurs.)

The logic is now changed.

When t_poll_retransmit expires we transfer all the SDUs in the wait list
having the same SN as the head of the wait list into the retransmit list.

Testing with Amarisoft UE, it seems to work properly.

Same commit justification as 50bf5713

integration_2023_w32

See merge request oai/openairinterface5g!2293

* !2061 Rel16 NR PRS improvements
* !2113 handle TDD pattern2 at UE
* !2266 Use cmake3 command if on RHEL
* !2287 Initialize OAIgraph before usage
* !2285 Fix alignment of Tpool user data to 32 bytes
* !2284 USRP driver: Make it compile for UHD < 4.0.0
* !2214 Use F1 Internally: switch to CU UE ID in CU

Via the include of the logging system, the ethernet transport
library implicitly depends on T. Hence, link T into
oai_eth_transpro.

This commit repairs the reestablishment after the introduction of the CU
UE ID in the CU, different from the DU UE ID. Now, the CU uses an
identifier different from the RNTI, used in the MAC, to refer to UEs.

To repair the reestablishment, a number of changes needed to be
introduced:

- Handle old_gNB_DU_UE_id in MAC

The MAC handles the old_gNB_DU_UE_id field in the DL RRC Message. The
commit adds encoding/decoding of the field. The MAC will drop the old
UE, but retain the CellGroup of the corresponding UE(!). Because a UE
releases the spCellGroup on reestablishment, the MAC does the same; it
needs to reapply the old configuration after a reconfiguration. For the
latter, introduce new variables to keep a "future" CellGroupConfig to be
applied (reconfigCellGroup) and a flag (expect_reconfiguration) that
applies the CellGroupConfig if a DL RRC Message transfer on DCCH, which
is assumed to be the reconfiguration.

- Add RNTI change in RLC

The RLC needs to reuse the old UE context. Hence, we simply change the
RNTI in the old context, and delete the new one.

- No PDCP UE ID change

The previous implementation of the PDCP used the RNTI; hence, the ID
needed to be switch (as above for the RLC). Since the PDCP now also uses
the CU UE ID, no identifier change is needed, and we remove all
corresponding code.

- No MAC modifications/update from CU

As foreseen by the spec, the CU does not modify or change the
cellGroupConfig in the RRC during reestablishment. This change will be
generalized in the future to all of the RRC.  Also, the
nr_rrc_mac_remove_ue() function has been removed: the MAC handles any UE
changes autonomeously, without being triggered from the RRC explicitly.

- Remove reestablish_rnti_map

The RRC does not use RNTIs for UE identification. Hence, a
reestablish_rnti_map to link two UEs to each other is not necessary
anymore.

After a reestablishment, the PDCP sequence number counters have to be
reset. Implement an API to allow the RRC to reset the sequence numbers
for a particular UE in the case of reestablishment

Plugin can trigger reestablishment (on DU)
and show counters of reestablishment (on CU)

The RRC gives its own RRC UE ID. It won't intervene if DUs assign the same RNTI to different UEs: it simply does not care what the DUs do with the RNTI.

- Use the same CU-UP in E1 as in CU-CP: we don't have a separate entity
  to allocate IDs, and we just use the same as the CU-CP
- Correct gNB CU-UP/CP UE IDs in E1AP message types to 32bit
- Set CU UP UE ID explicitly for clarity
- Remove RNTI from E1 messages, E1 does not know what an RNTI is

The UE had a list of known UEs. With the introduction of a separate
module for F1 UE ID handling that is also used in monolithic (to
separate CU UE ID from DU UE ID), this functionality is not needed, and
deleted in this commit.

Previously, the F1AP handler called various functions directly, instead
of sending an ITTI message to the RRC thread. This has two drawbacks:
- it can lead to data races if the RRC task uses functionality that is
  being accessed by the F1 task through this function
- no homogeneity: all other handlers send an ITTI message, so this one
  should too