Handover Request Message Processing
	- AMF selection respect to GUAMI
	- UE Context Creation in CU - NGAP
	- UE Context Setup Request with HO Preparation Information according to F1AP Spec

UE Context Setup Request Processing
	- If HO Preparation Information Exists, DU process this message in another function
	- Cell Group Configuration is created from target gNB's initial cell group. Then it is updated using UE Capability
	- Reconfiguration with sync IE is prepared similar to the used one for NSA

nr_pdcp_config_set_security function signature is changed and security_mode_completed input is added because from beginning we want to set pdcp_entity's security mode completed flag to true in case of handover.
Handover Request Acknowledge message preparation is done.
After reception of RRC Reconfiguration Complete message on target gNB; Handover Notify Message is triggered

- Triggering the Handover
	- gNB finds the best neighbour (only RSRP based)
	- gNB decides triggering the HO according to condition
		- bestRsrp > servingCellRSRP + HO Margin
		- HO Margin is an optimization parameter
		- For now HO Margin set to 0.

	- gNB prepares the current RRC Reconfiguration and binds to Handover
Preparation Information
	- gNB sends NGAP Handover Required Message towards AMF

- Reception of Handover Command Message on CU
	- Parsing of the message
	- gNB extracts the target gNB's RRC Reconfiguration from Handover Command
	- Wraps the target gNB's RRC Reconfiguration within DL DCCH Message
	- Prepares F1AP UE Context Modification Message
	- Sets Transmission Action Indicator to stop
	- Sends the RRC Reconfiguration with UE Context Modification
- Reception of UE Context Modification on DU
	- Pushes to RRC reconfiguration to RLC
	- transmission_stop flag is added under UE_sched_ctrl
	- if UE_sched_ctrl is true, gNB stops scheduling of the UE
	- DU sends UE Context Modification Response

- NeighbourCell and Measurement Configurations are prepared.

NeighbourCell Configuration includes:
	- neighbour_gNB_ID (This is needed for AMF to identify gNB exists in it's context
	- neighbour_nr_cell_id (This is needed for target gNB)
	- neighbour_physical_cellId (This is needed for UE in the meas report)
	- neighbour_absoluteFrequencySSB (This is needed for UE in meas report)
	- neighbour_subcarrierSpacing (This is needed for UE in meas report)
	- neighbour_mnc (This is needed for AMF)
	- neighbour_mcc (This is needed for AMF)
	- neighbour_mnc_length (This is needed for AMF)
	- neighbour_tracking_area_code (This is needed for AMF)

NR Measurement Event Configuration Includes:
	- enableA2 & enableA3 (gNB activates the event reporting according to these vars)
	- thresholdA2 & A2_TTT (configurable reporting parameters)
	- thresholdA3 & A3_Hysteresis & A3_TTT (configurable reporting parameters)

- These parameters are read in the configuration parsing part and written under RRC structure
- Event Based Measurement Configuration is prepared according to enableA3 parameter.
- Measurement Configuration of UE is cloned under UE Context. When a measurement report comes,
looping through the UE's meas config and matching the measIDs. With this measID, report configs
extracted and processing in different ways.

Integration: 2024.w06

Closes #733 and #732

See merge request oai/openairinterface5g!2564

* !2490 reworking configuration of LogicalChannelConfig at MAC UE
* !2548 NR UE MSG3 buffer
* !2556 Support RC SM aperiodic subscription for "UE RRC State Change"
* !2557 fix duplicate call of RCconfig_NR_L1
* !2550 use pointer to structure instead of module_id inside MAC
* address #733
* !2560 chore(ci): force rebuild of ran-base for integration branches
* !2495 Sidelink configuration passed from RRC->MAC
* !2220 L1 tx thread
* !2559 FH 7.2 improvements
* !2566 Provide right E1 instance when creating E2 agent in CU-UP
* !2513 Update NR SA tutorials

CUuniqInstance is also used for GTP module identification, which
uses the UDP server socket as its ID. This leads to arbitrary IDs (>0),
which is wrong.

Correctly show the path: it was missing cmake_targets/, although it is
there.

Closes: #733

Not periodically checking stats freeing can lead to asserts if these
lists are full. Check it once a frame to ensure that lists remain
non-empty.

	- Phy configuration will be prepared by MAC
	- Sidelink preconfiguration parameters passed from RRC->MAC
	- Only 1 SSB TA allocation used
	- psbch payload prepared by MAC after receiving the tx slss req

PUSCH decoding is started multiple times in nr_ulsch_procedures() for
each ULSCH segment, and stopped once inside
phy_procedures_gNB_uespec_RX(). Not only is it not clear if that works
with the API, it also might measure more than just PUSCH decoding.

Remove the PUSCH decoding, it is misleading. Check L1 RX processing
instead.

The CI would only detect a deviation from the normalized value based on
a configurable threshold, typically 1.25 (so we would tolerate a 25%
increase). However, it often happens that a timing gets shorter (e.g.,
forgot to put the timing measurements). This commit introduces a
"Deviation Threshold" (smaller than 1) to not only check that we exceed
1.0 + "Deviation Threshold" (as before), but also that are not below 1.0
- "Deviation Threshold".

In other words, assuming a maximum divergence of 25%, instead of just
checking if val > 1.25, we now also check if val < 0.75 (and flag
error).

This commit introduces a separate thread (l1_tx_thread) that processes
gNB DL/TX slots. It receives a message from the ru_thread when a new
slot started, and starts processing.

The DL part of the scheduler is run in the l1_tx_thread.  Therefore,
only call UL indication (for scheduler) in UL slots.  The UL indication
previously triggered the DL scheduler -- hence, it had to be called in
every slot. Now, since the DL scheduler is moved into the DL thread, we
don't have to call the scheduler in every slot anymore.

The reorder thread is removed, as reordering with this scheme is not
necessary anymore.

The main advantage of this version is that the TX can be scheduled
earlier (sl_ahead). Further, there can no longer be race conditions in
the TX path, since the scheduler/L2, TX L1 processing and the RU tx
function are all execute in the same thread (L1_tX_thread).

Also, the scheduler prepares PRACH/PUSCH/PUCCH FAPI PDUs. As of this
commit, the scheduler runs in the TX processing chain, whereas these
PDUs are destined for RX processing.  Thus, too avoid data races,
instead of triggering the RX processing at the same time as TX
processing in the RU thread, this commit changes the code to trigger RX
processing after the scheduler has been run in TX processing to avoid
data races.

Finally, we synchronize RU and L1 threads. This is important for
rfsimulator, since unlike most radios, rfsimulator can run slower or
faster, depending on I/O and CPU (it does not have a stable "tick").
Co-authored-by: kiran <saikiran@iitj.ac.in>

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

The UL_INFO_mutex is used in only one place, and therefore useless.
Also, the scheduler uses a lock internally to prevent concurrent access.
Hence, the UL_INFO_mutex is not needed.

Remove kill_gNB_proc(), as it is now dead code.

The next commit introduces a separate gNB TX processing thread. To
properly separate DL scheduler (for scheduling decisions) from UL
indication handling (for UL packets), this commit introduces a slot
indication "tick" to run the DL scheduler which will be put into the gNB
TX processing chain instead of the UL indication.

For different reasons, the frame/slot numbers might jump (e.g., gNB and
RU machines not properly synced). The scheduler would assert for PUCCH
allocations. Handle this gracefully by printing an error message, and
resetting the PUCCH structure.

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).