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

Merge remote-tracking branch 'origin/implement-dci11-type0-contiguous-rbs' into integration_2024_w17