In the case of PDU sessions in the NG UE context setup request, we first
have to set up security. Hence, in this commit, implement the "delayed"
set up of theses PDU sessions, and acknowledge the setup request after
reconfiguration, as requested by O-RAN.WG5.C.1-v11.

Trigger UE ctxt setup response for the case of "registration request"
(no PDU sessions in UE Context setup response), as mandated by
O-RAN.WG5.C.1-v11.

As of this commit, since we now send the UE security command as a DL NAS
message, there is no F1 UE Context setup request. Hence, instead of
sending a UE context modif request, send the UE context setup request
after the E1 bearer setup response (which logically also makes more
sense, as the E1 setup procedure comes before the F1 setup procedure).

This reverts commit 0f100a6e, which
introduced a hack to possibly wait with a PDU session setup at the RRC
in case a RRC UE capability transaction (requesting UE capabilities from
a UE) was ongoing. This happened, as we delayed the UE capabilities to
after the first RRC reconfiguration; in that case, certain UEs were
requesting the next PDU session, and if RRC did not delay the new PDU
session (as requested from the core), this procedure might occur while
UE capability enquiry was ongoing, leading to failures in these
transactions.

The default RRC reconfiguration was previously sent after the security
mode command as a "first" RRC reconfiguration. However, it is simply not
needed, as it will be triggered through a subsequent reconfiguration
that also sets up DRBs.

Move the Measurement Config to the "other/dedicated" RRC
reconfiguration.

This reconfiguration would have forwarded a NAS PDU (typically a
registration accept). This is now done by a dedicated forwarding of NAS.

This reverts commit 4a7d7975.

Trigger the UE capability right after security mode complete, as
specified in O-RAN WG5.C.1-v11. Also, there is no "need" for the
"default" RRC Reconfiguration (it will come once PDU sessions are
requested), so remove this as well.

Previously, the CU sent the Security Mode Command as part of a UE
context setup request. This was done "because it was possible", not
because there was an inherent need to do this. However the LiteOn DU
does not like this, as it expects to also have a DRB in the UE context
setup request procedure, which is not always the case.

Hence, send the Security Mode Command in a normal DL RRC msg transfer
over F1. As of this commit, there is not UE context Setup Request (so it
might not work with all DUs), but the OAI DU is cool and does not care,
so RFsim still works.

This also aligns the CU's behavior with O-RAN.WG5.C.1-v11.

Finally, as of this commit, we do not trigger a UE context setup
request, so we cannot handle PDU sessions inside the initial UE context
setup request at the same time as the security mode command (which was
done previously before reaching this point). This will be fixed in a
later commit.

In the DU, read slice information from the DU config file. Handle
multiple slices within the F1 Setup Request structure representation,
and forward it via F1 to CU. The DU slice information is stored in the
setup request structure.

This reverts commit eaf28414.

This assertion was introduced as we (wrongfully) thought we needed to
calculate the SSB ARFCN at the CU. Since PBCH might carry one bit, which
is not available at the CU, only certain SSB ARFCNs would have been
possible.

With the availability of the SSB ARFCN through the
MeasurementTimingConfiguration, this is not necessary anymore.

MeasTimingConfig may not come with F1 Setup Request: some DUs send it
with the DU configuration update. Handle this gracefully by checking for
MTC before using it.

Refactor parts into a separate function, which will be reused within the
gNB-DU configuration update function in the next commit.

The OAI DU does not use this message, and could not roll-back. The
LiteOn DU does not seem to like it. It is useless (as of now), so remove
it

Use the correct MIB data structure, MIB_t. This is required by 38.473,
and the LiteOn DU sends only that. So our CU needs to handle it, so
align the OAI DU as well.

For docker version > 25.0.5, "version" field is not relevant and reported as obsolete.

Integration `2024.w17`

See merge request oai/openairinterface5g!2702

* !2659 NR bandwidth index fix
* !2693 Harmonize frequency range structures
* !2699 Add support for USRP X410 to run with 200 MHz bandwidth in FR2 at 120 kHz SCS
* !2692 Fix for the overflow issue while processing GPS based timestamp from RU
* !2665 NR UE improvements in handling RRC Release
* !2682 dci11type0
* !2686 CI: Maintenance, fixes, improvements
* !2677 NR UE trigger RA for SR failure
* !2683 Ue small fixes
* !2668 Refactor PDCP Reestablishment and introduce PDCP Suspend at gNB
* Add rhel9.4 to the list of OAI supported distributions
* !2673 speedup integrity computation
* !2706 doc: Update of CI testbenches

- according to clause 5.3.7.2 of 3GPP TS 38.331
  PDCP Suspend is not required during RRCReestablishment

- according to 5.3.7.4 of TS 38.331: 1> re-establish RLC for SRB1;
- gNB:
1) re-establish RLC for SRB1 in nr_rlc_update_id
2) re-establish RLC for remaining RBs concurrently with RRCReconfiguration

issue: gNB) in nr_rlc_update_id the gNB is re-establishing RLC for all
            RBs at the same time when receiving RRCReestablishmentRequest
            from UE
        UE) according to the specs, the UE is re-establishing RLC for
            SRB1 with RRCReestablishmentRequest the other RBs are
            re-established during RRCReconfiguration (in our case in
            nr_rrc_ue_process_RadioBearerConfig) when receiving
            reestablishRLC IE in rlc_BearerToAddModList
    RLC TX) this leads to RLC counters mismatch after re-establishment:
            control PDUs discarded until max nb of retx is reached
            and then UL failure occurs

- replace nrmodule2 by up2
- add matix in CI machines
- add info about RAN-SA-2x2-Module-CN5G in list of pipeline
- update of 5G OTA testbench image