Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

uper_encode_to_buffer() of asn1c returns the number of BITS that have
been encoded; if we use this, we need to calculate the resulting number
of bytes (rounding up) to get the right buffer size.

Note that do_NR_ULInformationTransfer() uses
uper_encode_to_new_buffer() which returns the number of BYTES, hence, in
this similar function, we should not modify the return value.

add a function to reset the transmission timestamps chain, and use it in context of UE resynchronization

Integration `2024.w18`

See merge request oai/openairinterface5g!2713

* !2705 Fix CRC check in UE DCI detection
* !2708 Adding few more NR bands to the list of supported ones
* !2701 gNB archi fixes
* !2203 DL-MMSE
* !2684 remove asserts on min RX/TX, set the RX/TX shift as 2 in the UE
* !2594 F1AP refactoring to align with O-RAN.WG5.C.1-v11

Taking the example of the AMF Set ID, the previous version of the macro
used another macro to encode the number, then marked the last 6 bits in
the bit string (of length 16/2 bytes) as unused. This is wrong, because,
assuming AMF Set ID=3, it basically truncates the number by encoding all
16 bits and cutting off the last 6, like this:

  ------------------- encode 16 bits
  0000 0000 0000 0011
  ------------        take these 10 bits

So what remains is these bit positions of the number:
(16,15,14,13,12,11,10,9,8,7) -- the last 6 bits are cut (and the first 6
are either 0 or garbage, because they don't exist).

Instead, manually encode bits (10,9,8,7,6,5,4,3) in the first byte, and
(2,1) in the second byte of the bit string, like so:

  ------------        encode 10 bits
  0000 0000 1100 0000
  ------------        take these 10 bits

Do the same with the pointer.

The AMF Region ID above is correct, as it is exactly 8 bits.

We can optionally indicate the PDU session IDs. At least with OAI 5GC,
that should help it clean up.

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.