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

- harmonize monolithic and E1AP case
- use ITTI message to send bearer context setup response to RRC

This allows to communicate with multiple remote hosts. A further
improvement would be to refactor this piece of code into a function and
call it only when necessary, i.e., when we know the remote host, or want
to add one to a list of hosts.

Call __builtin_popcountll function to count the number of bits set in uint64_t variable for polar codes

This commit introduces the capability to handle multiple CU-UPs. It uses
a RB tree and puts the CU-UPs into the tree. Upon the connection, it
associates UEs to CU-UPs in a round-robin fashion.

A later commit will introduce an RB tree to manage multiple CU-UPs. The
RB tree implementation relies on some macros that generate RB tree
functions. Functions using the RB tree implementation will be grouped in
this file.

The E1AP Setup Request contained the network configuration (IP address,
ports) as well as the actual E1AP Setup Request application data
(Supported PLMNs, ...). This has the drawbacks that
- The E1AP Setup Request is stored to retrieve IP addresses in the E1AP
  module, which is confusing as the Setup Request, per standard, has no IP
  info
- The CU-CP received an E1 Setup Request for configuration during start
  up, but it did not actually receive such Setup Request, but merely the
  IP configuration to set up the socket

This commit splits the E1AP Setup Request into a "real" Setup Request
for application data, and creates a new type e1ap_net_config_t to group
all IP configuration data. Further, a new ITTI message type
E1AP_REGISTER_REQ is introduced to group both types. What happens is
- RCconfig_NR_CU_E1() reads both E1AP application-level data and IP
  configuration, as previously
- The data is sent to the CU-CP. It discards the E1AP Setup Request
  data, and only uses the network configuration to set up the socket
- The data is sent to the CU-UP. It uses the network configuration to
  connect to the CU-CP, and then sends the E1AP Setup Request to the
  CU-CP.

Currently, the CU-CP still stores the Setup Request locally, which will
be changed in the next commit to send it to the RRC.

- e1ap_encode_send(): do not use E1AP Setup Request
- store assoc_id in the instance, and reuse that