This branch series implements the usage of the F1 Setup Request
internally at the gNB, even if CU and DU run in the same process. Until
now, the F1 Setup Request contained struct fields to pass IP
configuration to the F1AP module; this information is not necessary in
monolithic, nor should it be relevant when passing the information in
F1 Setup Request.

Therefore, this commit moves all IP connection-related information out
of the F1 Setup Request and into a separate structure instead.  In order
to give the F1AP module the necessary connection information, the
DU_REGISTER_REQ message is introduced that combines the F1 Setup Request
and IP configuration, such that the F1AP module can setup the SCTP
connection and then send the F1 Setup Request message.

In a later commit, there will be a callback for F1 Setup Request at MAC
to simply register the DU at the CU. The monolithic callback will simply
forward the F1 Setup Request The F1AP callback will look up the IP
configuration and create DU_REGISTER_REQ message containing IP
configuration and F1 Setup Request, which is then handled by the F1AP
module. To this end, a separate function in gnb_config.c allows to read
IP information from configuration.

Instead of storing the F1 Setup Request implicitly in F1 context, we
provide the F1 Setup Request message to be encoded explicitly to the
encoding function.

We ever only have one instance, so hard code that.

In the case of MIMO, we reused memory to point to the same PUCCH
resource. This is problematic, since ASN_STRUCT_FREE() would try to free
this resource twice.

This commit changes to create distinct memory for the PUCCH resources,
while putting the same configuration to still use the same PUCCH
resource from a radio configuration point of view.

integration_2023_w37

* !1909 Rework for aarch64 support after SIMDe integration
* !1995 Fix packing/unpacking for nFAPI P5 messages
* !2228 TDLA, TDLB and TDLC channel models in DLSIM
* !2327 Bugfixes and some rewrite for nr rlc am control PDU reception
* !2331 NR UE HARQ improvements to handle more than 4 per PUCCH
* !2286 Service Models integration - KPM v03.00, GTP, MAC, RLC and PDCP
* !2336 fix(ci): HTML reporting for Ubuntu build fix
* !2338 nr-softmodem: fixed invalid length calculation, leading to segfault
* !2326 Tutorials: Update NR SA Tutorials to be compliant with OAI CN5G pre-2.0 release
* !2334 NR UE DL channel estimation fix
* !2325 Compute ULSCH TB CRC

Laurent noticed it on one of his MR and confirmed with him:
  -- Volumes have be created the 1st time they ran on avra on July 7th
  -- Volumes were created with not only the raw files but also the nr-softmodem executable

Solution: two-fold:
  1. using the `docker-compose down -v` syntax, the volume is deleted automatically
  2. I added redundancy with the custom command to remove the used volume
Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Merge remote-tracking branch 'origin/dreibh-trx_usrp_read-memory-access-fix' into integration_2023_w37

Merge remote-tracking branch 'origin/raphael/ci-fix-ubuntu-build-log-scheme' into integration_2023_w37

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

- when CU is used, UE ID data is filled as GNB_UE_ID_E2SM with
  CU UE ID value included

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

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

fix(ci): docker_log_split is useless with current build scheme. Just copying all txt files from ran-build image
Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

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

- Fix 4G and 5G discrepancy in TLV padding requirements: 4G does not
  need padding, whereas 5G needs, so make separate set of function for
  padding for NR
- Fix packing/unpacking for (n)FAPI PARAM and CONFIG.request/response
  messages
- Handle message padding to next 32-bit boundary, as per SCF
  specification in packing and unpacking functions
- Account for message header size upon receiving message in PNF and VNF

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

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