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.

This has no meaning at a global level, we run several slots: one tx,
several rx at same time. Some minor cleaning of C style

The external declarations were incorrect, leading to mismatching
prototypes of config_ru and config_rru (true bug in OAI lte!).

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

- 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

By using a struct we may have warnings at compilation time in some
cases if the type is not used properly.

The type definition becomes a bit weird, so we need to properly
comment.

If too strange, we can revert to the classical "void" definition.