We AssertFatal() if integrity fails. To be refined if needed.

The case securityModeFailure didn't seem to be implemented
properly, so I just removed it entirely.

The variable 'securityMode' did not make much sense, removed as well.
Plus for integrity, there was: securityMode |= 1 << 5 for nea1
and << 6 for nea2, which does not seem correct (I would expect << 4
and << 5 respectively), so it was properly incorrect.

'securityModeCommand->criticalExtensions.choice.securityModeCommand'
was accessed before checking that
'securityModeCommand->criticalExtensions.present'
is 'NR_SecurityModeCommand__criticalExtensions_PR_securityModeCommand',
which is wrong.

The tests 'securityMode >= NO_SECURITY_MODE' and 'securityMode != 0xff'
don't make sense/are unclear, so removed too.

So let's simplify this function, wrong in several places. And put
some AssertFatal() so that the code won't do weird things. The
AssertFatal() can be removed later and the function improved later
if needed. The case securityModeFailure can also be handled later,
but I think there is more work to do than just encoding the message
and send it to the gNB, so it's not bad to remove it for the moment.

Needed by some RRC procedures to validate the integrity of a message
before accepting it.

The use of security_mode_completed in the PDCP entity was a hack.

Plus it was not working at all with the deregistration request
when nea2 is used, sent when doing ctrl+c in the nrUE.

So let's remove it.

And let's handle activation of integrity and ciphering more in
accordance with what 38.331 says. SecurityModeComplete has to
be sent integrity protected, but not ciphered. Only after should
the ciphering be activated. (See 38.331 5.3.4.3.)

feat(doc): suggested changes: realtime tuned profile, kthread_cpus formulation and further details in PTP pining

feat(doc): update O-RAN 7.2 doc: details in kernel thread isolation, kernel thread isolation for solving PTP clock lag, PCI address of VFs

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>