as per standard (see 33.501 6.4.3.1, see 24.501 4.4.3)

Get the security algorithms from SecurityModeCommand.

Restructure the code a bit: add the function handle_security_mode_command()
and adapt the code to use it.

Derive also knas_enc (not used yet).

Do the derivation for knas_enc and knas_int only after reception
of SecurityModeCommand. We need the algorithms configured by core
network to derive those keys.

Specs (24.501, 33.501) don't seem to mention mm_counter and sm_counter,
simply nas_count, let's use this.

Integration: `2024.w21`

See merge request oai/openairinterface5g!2757

* !2733 Remove duplicated function to reverse N bits
* !2712 rfsimulator: add support to simulate a long propagation delay
* !2695 improve polar init and polar readability
* !2709 Fix cmdline configmodule in phy simulators
* !2756 remove some enb dependencies in NR files
* !2687 bug fix ue UL payload filling randomly done in retransmissions (pointer not set)
* !2543 power/PHR normalizations for deltaMCS power adaptation
* !2719 Refactor LC handling at MAC
* !2736 Fix debug for ongoing transactions
* !2747 Fix aerial memory leak
* !2761 Use timeout command to kill hanging iperf3
* !2752 fix-dci11-type0-bitmap-setting
* !2759 Fix invalid MSG2 HARQ feedback attempt and remove accumulated_delta_PUCCH field from UE FAPI IF
* !2740 bugfix/cleanup: remove uint8_t to encode size plus some cleanup
* !2760 fix 5G NR SA FDD configs for 24 and 25 PRBs
* !2520 Documentation on coding style, workflow, and review instructions

It can happen that in the current DL slot, we cannot send an allocation
for Msg3 in a later UL slot. Up to this commit, MAC printed a warning.
However, this is not really a warning, as it will likely work in the
next or a later slot. So demote this to debug.

The starting point was the function do_NR_DLInformationTransfer() which
may deal with more than 256 bytes.

Then why not cleanup all the functions in the same file.
(And do a bit of formattting fixing while we're here.)

Then cleanup the callers of those functions.

Then, because of do_SIB23_NR() let's also cleanup in some
structures.

Not all the codebase was cleaned up, there surely remain some uint8_t
(and char/short/uint16_t) which are wrong.

UE was attempting to send ACK on MSG2 - was caused by missing brackets in if statement.

Merge remote-tracking branch 'origin/Fix_array_for_debug_ongoing_transactions' into integration_2024_w21c

Set appropriate length for csi payload calloc and memcpy, according to bit_len

In some pipelines, it happens that iperf3 is hanging on 100% CPU load.
In these cases, a simple TERM signal does not seem to be enough to kill
it; KILL is necessary.

While e.g., RemoteCmd's driver paramiko has a timeout command, the
documentation [1] is not really clear how it is trying to stop commands.
Since it effectively does not stop, we have to assume it is only sending
TERM.

To remedy this, use the timeout command to start iperf3. We use option
-v for diagnose timeouts on stderr, and send KILL after an additional 3
seconds (-k3) if TERM does not succeed. The timeout is sent to the same
duration as the overall iperf timeout.

[1] https://docs.paramiko.org/en/3.4/api/channel.html#paramiko.channel.Channel.settimeout

make sure the SSB is offset by 4 PRBs from the BW start.
Therefore, the ARFCN for the SSB center must be offset by 14 PRB from the ARFCN for the BW start.

Merge remote-tracking branch 'origin/fix-ue-ul-retransmissions-payload-copy' into integration_2024_w21c

A to-be-added UE's RA is added through nr_mac_add_test_ue() (the name is
misleading, it is not a "test UE") through its CellGroupConfig. Using
the process_CellGroupConfig() is unfortunate, because it is not really
clear what part of the CellGroupConfig gets evaluated (it is certainly
not all). Move the code for adding a new RA directly in the user-add
function, and refactor this one.

Introduce new LC configuration "priority", as specified in 38.321, and
use to sort LCs by priority. We set the priority of an SRB according to
38.331 Section 9.2.1, and for a DRB to be the minimum priority of the
QoS flows associated to this DRB.