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

Integration `2024.w13`

Closes #696 and #762

See merge request oai/openairinterface5g!2653

* !1911 Preparatory work for NR DL 4-layer MIMO at gNB
* !2610 fix ug on pilot 2 in nr_pbch_dmrs_correlation() that is lacking signal...
* !2639 NR gNB PUCCH2 CQI workaround
* !2642 NR UE demoting to LOG_D another log that cause flooding
* !2644 NR UE prevent segfault at detach
* !2645 add error code for pdu session reject in the ue
* !2600 Handle Msg3 with SRB1 RRCReestablishmentComplete and MAC CE C-RNTI
* trigger RF-sim E1+F1 test without asan
* !2636 Fix various F1 problems
* !2641 NR DL and UL channel estimation fix
* !2652 Provide additional troubleshooting documentation for QtScope
* !2646 NRUE fix asn_sequence_del to clear a list
* !2504 CI: use iperf3, refactor Iperf_Module
* !2617 use UE ID instead of RNTI internally in NR RLC
* !2619 Minor PDCP fixes
* !2648 Minor CI fixes, stack protection, fix E1+F1 Quectel test, L2sim5G test

Merge remote-tracking branch 'origin/NR_UE_fix_wrong_use_asn_sequence_del' into integration_2024_w13

Merge remote-tracking branch 'origin/NR_fix_layer_port_confusion_channel_estimates' into integration_2024_w13

Merge remote-tracking branch 'origin/Fix_Msg3_RRCReestablishmentComplete_with_C-RNTI' into integration_2024_w13

Merge remote-tracking branch 'origin/demote_another_log_printed_too_many_times' into integration_2024_w13

On Wayland (e.g., Gnome on Ubuntu 22), additional steps might be
necessary to make QtScope run. Describe them in the doc.

Closes: #696

- this prevents pulling PDUs from PDCP when re-establishment is awaiting

- short and long SN sizes
- PDCP PDU header sizes
- PDCP integrity size
- getter for maximim PDCP PDU size

From 3GPP TS 38.321 Section 5.4.3 Multiplexing and assembly, we need to process the highest priority subPDUs first:
- MAC CE for C-RNTI is the one with higher priority

38.473 section 8.2.3.1 says that upon F1 Setup Request, UE associated
signalling should be erased. In this commit, we trigger a release of all
UEs that were still connected to a DU when we received the SCTP
shutdown, i.e., when the DU disconnects.

Closes #762

Explanations: see #706. TLDR: the RRC code calls nr_pdcp_remove_ue(), so
we should not call it in the E1 handler if we do not use split mode.