Merge remote-tracking branch 'origin/NR_UE_handling_MCS_for_retransmission_v2' into integration_2023_w44

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.

Not initalizing this struct makes asn1c free the memory incorrectly,
leading to a segfault.