As with the ServingCellConfigCommon, the ServingCellConfigDedicated is a
radio-related structure to be handled at the DU.

Note: the reestablishment is broken, and a later commit fixes it.

The ServingCellConfigCommon is an inherently radio-related
configuration. As such, it should be handled by the DU, not the CU.
Therefore, move it "down" to the MAC.

The PCI is given to the CU from the DU in the F1 Setup Request message.
It is a part of the DU, so move it "down".

The F1 Setup Response contains the cell(s) to activate. Hence, prevent
the radio from starting by waiting for the F1 Setup Response before
continuing.

- send F1 Setup using callback
- store f1 setup req locally for reference
- check F1 Setup Req against RRC data structures:
  * if matches: send F1 Setup Response using callback
  * if not matching: send F1 Setup Failure using callback
- don't send CU config update by default, we don't need this
- if the Setup Response does not contain a cell, don't activate. It is
  possible the CU sends a gNB-CU configuration update, which will
  initialize the structures

Use a struct to initialize the RRC at the beginning, and remove the
NRRRC_CONFIGURATION_REQ. This message is not necessary; the RRC/CU
should be initialized from the F1 Setup Request, coming from the DU.

Before this commit, we did not read the ServingCellConfigCommon (SCC)
completely at start; rather, we read most (but not all) of it, then also
the minRXTXTIME, and at RRC initialization in
openair_rrc_gNB_configuration(), we filled the
pusch-TimeDomainAllocationList into the SCC, depending on the
minRXTXTIME.

The reason might be that we read part of the SCC, use that to fill the
NRRRC_CONFIGURATION_REQ, read also the minRXTXTIME (part of the RRC
config), and then we have all we need to "finalize the SCC". Since we
move everything to the MAC, I avoid too much upfront code changes,
hardcode the minRXTXTIME (and check with an assert), and undo this in a
later commit when the "RRC config" relevant for radio parameters, e.g.,
minRXTXTIME, is moved to MAC.

I verified the equality of the SCC before (at the end
openair_rrc_gNB_configuration()) and after (at the end of
get_scc_config()) this commit manually using a printf, assuming that
after RRC initialization, we didn't do any further modifications to the
SCC.  But in fact, I cannot know that we don't do it...

- Simplify code by reading the SCC in a separate function
- Fill the F1 Setup Request message correctly in case of FDD, from SCC

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>