Disable DPDK telemetry to skip creation of one/two threads (depending on
DPDK version). To force users to do this, bump the version of the patch
checked by cmake.

More information on DPDK telemetry:
https://doc.dpdk.org/guides/howto/telemetry.html

Closes: #732 (suggestion 2)
Suggested-by: Andrew Sergeev <andrew.sergeev@adtran.com>

Force the CPU affinity for ru_thread explicitly to ru_thread_core. It is
already done via threadCreate(), but force again as per change request.

Delete commented 7.2 code that did the equivalent. We cannot set it in
the driver, as we don't have access to variable ru->ru_thread_core.

Closes: #732 (suggestion 2)
Suggested-by: Andrew Sergeev <andrew.sergeev@adtran.com>

system_core is the core reserved for DPDK control threads. It was
hardcoded to 0, but it seems that one some systems, CPU 0 cannot be
reasonably isolated from kernel threads. Make it therefore configurable
(default: 0)

Closes: #732 (suggestion 1)
Suggested-by: Andrew Sergeev <andrew.sergeev@adtran.com>

Use configured
- FFT size
- numerology
- slot number

Necessary for FR2 operation and different FFT sizes (as opposed to
FR1/4096).

The gNB configuration depends on DPDK (e.g., PCI addresses). Therefore,
put DPDK config before, to keep it logically ordered.

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Integration: 2024.w05

See merge request oai/openairinterface5g!2549

* !2537 Fix for UE PUSCH scheduler DURATION_RX_TO_TX assertion
* !2538 Fix for UE MAC PDU LCID handling
* !2542 Fix L1_SSB_CSI_RSRP table mapping and check validity
* !2544 NR UE RRC timers improvement
* !2546 Correcting the location of packages
* !2493 Fix for computing SSB subcarrier offset
* !2496 MCS for retransmission fix in case of dci failed detection at NR UE
* !2503 Handle PDU Sessions in NG Initial UE context Setup and forward 5G-S-TMSI to core
* enable caching in the docker build of the CI build steps
* !2541 Fix RA bug, improve overall logging

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Merge remote-tracking branch 'origin/NR_UE_fix_no_mcs_dci_failed_detection' into integration_2024_w05

We used to trigger the UECapabilityEnquiry right after
SecurityModeComplete, and before the RRCReconfiguration (which we call
"default" reconfiguration). However, 38.401 tells us that we should send
the RRCReconfiguration right after the SecurityModeComplete. In fact,
even though we get the UE capabilities, we cannot use them during this
reconfiguration, as we would first need to update the DU with a UE
Context Modification Request, which we cannot, as we just sent the UE
Context Setup Request, and the DU relies on first getting the
RRCReconfiguration.

Since we rely on a subsequent reconfiguration anyway, we can safely
trigger the UECapabilityEnquiry after RRCReconfigurationComplete.
(38.331 also says we can send UECapabilityEnquiry at any point.)

To cater for the possibility that there might not be any reconfiguration
coming afterwards, we check if a DRB has been set up. If not, we assume
a reconfiguration will come, and do not trigger one only for the UE
capabilities (this is what we do before this commit). If we already have
DRBs set up, they might have been set up during the "default" RRC
Reconfiguration, and another reconfiguration might not follow soon; in
this case, we trigger the reconfiguration by sending the UE capabilities
to the DU right away.

The next commit moves the UE Capability Enquiry after the first
reconfiguration. This has the effect that for some UEs (e.g., iPhone),
the Setup Requests come too close to each other, triggering RRC
Reconfigurations while previous transactions are ongoing.

I think the "true" solution would be to implement some tracking of
transactions across RRC, F1AP, E1AP, but this might require many
changes. For the moment, limit to delaying PDU session resource setups
to prevent above problem. Delaying is done using ITTI timers (to be able
to serve other UEs), waiting 10ms each time, up to 20 times (to not
deadlock the transaction -- after all, if the UE is unhappy, it will
drop the connection).

- Put consistently transaction IDs
- Remove transaction IDs when transaction finished, or in places that do
  not trigger an RRC transaction

This commit allows the gNB to handle PDU sessions that the core requests
to setup during the NGAP Initial UE Context Setup. Previously, we only
managed them as part of PDU Session Resource Setup Request.

The RRC will, depending on whether a PDU session is in the NGAP Initial
UE Context Setup, either directly trigger the Security Command, or first
do a bearer setup at the CU-UP. Some asserts have been lifted, as now
the PDU sessions might be present before the RRC Connection is fully
established.

Implement the correct forwarding of the bearers in an F1 UE Context
Setup Request message.

This solves bug #672.

Prior to this commit, the handling of DRBs is complex: first the RRC
"guessed" a DRB ID when setting up DRBs via E1AP (in
rrc_gNB_process_NGAP_PDUSESSION_SETUP_REQ()), and later chose one for
real in fill_DRB_Configlist() (called in
rrc_gNB_generate_dedicatedRRCReconfiguration()).

To simplify, remove fill_DRB_Configlist(), and instead allocate the DRB
using generateDRB() before sending the message via E1AP, in
rrc_gNB_generate_dedicatedRRCReconfiguration(). The rest of the logic is
the same.

For PDU sessions, always mark PDU sessions as "done" to match pdu
session state logic.

It might happen that a UE has no CU-UP (e.g., never requested a PDU
session). When triggering a release, we previously and implicitly
associated a CU-UP in that case. That is not good, and confusing.

This commit adds a function to look up if the UE has an associated
CU-UP. We only send a release if it is the case.

The function get_existing_cuup_for_ue() now instead verifies that a
CU-UP exist, and does not implicitly create an association (which might
be unwanted, see above).

The number of tunnels corresponds to number of DRBs, so correctly
compare tunnels and DRBs.

The function rrc_gNB_process_RRCReconfigurationComplete() does almost
nothing, we can delete it.

The variable name ue_reconfiguration_after_reestablishment_counter is
misleading, as it counts all reconfigurations; rename to make it clear.

The drb_active array keeps track of active DRBs. However, it only
replicates some of the information in established_drbs, and could lead
to a reuse of DRB IDs when two bearers are to be set up. Consider the
following:
1. trigger first DRB creation at RRC
2. DRB ID chosen from free drb_active entry
3. trigger second DRB creation at RRC
   -> The first reconfiguration has not been acknowledged
   -> drb_active is not marked as DRB_ACTIVE
4. The second DRB ID is chosen from a free drb_active entry, which is
   the same as in 2.

By reusing established_drbs everywhere, this cannot happen, as we
1. select the DRB to be used using next_available_drb() and then
2. use generateDRB(), which marks the DRB used
all from within fill_DRB_configList, which gives a new DRB.

The logic is still overly complex, though.