This code printed BW masks (what is this) and number of MIMO layers. It
was dependent on the current DU, and only showed the information for the
current DU config (SCS, band). On DU disconnect, it leads to segfaults
to this dependency, and IMO is not useful in itself (it could rather be
printed when receiving the UE capabilities, for all bands etc.).

To allow to send F1 messages to multiple DUs from the CU, we need to
send these messages via different assoc_id (SCTP association ID,
basically akin to a file descriptor). Currently, the assoc_id is stored
in a context at the F1 module and retrieved in
f1ap_itti_send_sctp_data_req().

To facilitate a later change towards indicating (from the RRC) to which
assoc_id (hence, DU) to send a message, we refactor all
CU_send_*()/DU_send_*() functions to take the assoc_id as a parameter to
which to send messages. In this commit, we then pass the assoc_id from
the context. A later commit changes this (at the CU) to pass the
assoc_id from the message to be sent.

Previous to this commit, the CU creates an F1 instance and initializes
GTP after a successful connection establishment, and tears the F1
instance down after the DU disconnects. This does not work when trying
to connect multiple DUs, or have them reconnect, as e.g., GTP
re-initialization fails (socket already bound).

This commit makes the CU F1 instance creation and GTP init at CU task
init (only once), and also frees the F1 instance only after the CU task
exits, which is at termination of the application, typically.

Remove dead code, result of 2136ceec: we
cannot connect() in GTP on multiple remotes (as then only packets of one
host might be received), but might need to send to multiple remote
sockets.

integration_2023_w43

See merge request oai/openairinterface5g!2415

* !2407 hotfix: UE DCI format 11: only 1 dl_config instead of 2
* !2372 chore(ci): testing up to 10 UEs in 5G RF simulation
* !2396 Add optimized function to count the number of bits set in uint64_t variable
* !2383 E1: implement release bearer, handle multiple CU-UPs
* !2413 Assigned value is garbage or undefined reported by scan-build
* !2387 Small fixes for UE stability and introduction of ITTI "no-thread" mode (separate bug fixes and ITTI changes?)
* !2410 Fix CellGroupConfig-related memory problems
* !2414 fix doxygen

Merge remote-tracking branch 'origin/assigned_value_is_garbage_or_undefined' into integration_2023_w43

- Set the correct QoS flow ID to associate a correct QoS flow to the
  bearer: the UE would misassociate otherwise
- Set the DRB as the default: the handler applies bool with true==1, so
  use bool value

Introduce a --no-itti-threads command line option to disable threading
in ITTI, and call message handlers in the current thread. This is being
introduced in order to increase repeatability when testing the nrUE with
the IQPlayer. Without this feature, runs with the IQPlayer will end up
differently, depending on the timing of ITTI threads, mostly when
sending messages to RRC and NAS.

Messages are pushed using pushNotifiedFIFO(), so we pullNotifiedFIFO()

Before this commit, the DMRS_UplinkConfig was stored in a separate
DMRS-related structure, although it is always referenced in the
PUSCHConfig of the current UL BWP.

Through certain code paths (e.g., retransmission), it could happen that
an old DMRS_UplinkConfig was accessed that was freed (through new
CellGroupConfig).

In this commit, we always look up the DMRS_UplinkConfig in the current
PUSCH config, which should always be up to date.

Until this commit, the SIB1's PDCCH_configCommon was set (via a pointer,
i.e., an indirection) to the one of the ServingCellConfigCommon (SCC).
Afterwards, the SIB1 code further populated this PDCCH configCommon,
indirectly populating the one of the the SCC, on which code later
depends.

Not only did this create possibilities for double-frees (since freeing
the memory of SIB1, then SCC would free the PDCCH configcommon twice),
but also it makes it harder to track where certain structures are
populated. Hence, this commit solves both issues:

- The SCC is correctly populated on initialization of the SCC
- The SIB1 makes a deep copy of the SCC' PDCCH configCommon

This resolves the two issues above.