- PDCP reestablishment on CUCP (DRBs) triggering Bearer Context Modification procedures over E1
- Performing PDCP reestablishment for requested DRBs on CUUP
- Introduced function to notify re-establishment to CU-UP
- removed call to PDCP reestablishment for the DRBs on CUCP (it's done on CUUP)

- many structs and definitions are overlapping between the two different E1 procedures
- introduced naming specific to E1 Bearer Context Modification to improve readability
- grouped SDAP and PDCP configuration IEs for better reusability and readability
- introduced functions to set and get default PDCP config (DRBs and Bearer Contexts)

see !MR2545 for more context

- it triggers the RRC callback after SCTP SHUTDOWN indication
- CUUP entity cleanup at RRC level

- CU-CP replying to the CU-UP with a Setup Failure message in case of unsuccessfull E1 Setup Request
- message is decoded by the CU-UP, and stops the process

- Implement: Extend the F1 encoding and decoding with Qos
- Implement: E1 decoding for QoS
- Fix: Modify the UE_MODIFICATION_REQUEST_MSG towards DU to contain QoS info based on E1AP context response
- Fix: Modify the E1AP and F1AP message structures
- Fill the Qos configuration to send to MAC

3GPP has the concept of a gNB-CU-UP ID and a (separate) gNB ID (for gNB,
CU-CP). This commit introduces the gNB-CU-UP as a separate ID that has to be
set in the configuration file when running as a CU-UP. For the
CU/monolithic gNB, it is optional (but needs to be the same as the
gNB-ID if specified).

The CU-UP ID is necessary, as some entities, e.g., the e2 agent, need to
signal both IDs, e.g., to reconcile a CU-CP and (multiple) CU-UP(s)
belonging together.

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

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.

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

The DRBLists inside E1AP message are for E-UTRAN. We don't support that
with our CU-CP/UP yet, so remove it to reduce ambiguity and complexity.
For the same reason, we remove the CN Support, which for us is always
"NR".

- Global variables that are never written to are marked const
- Remove some EXTERN declaration
- Remove unused `log_mem_multi` from logging module

- Use the same CU-UP in E1 as in CU-CP: we don't have a separate entity
  to allocate IDs, and we just use the same as the CU-CP
- Correct gNB CU-UP/CP UE IDs in E1AP message types to 32bit
- Set CU UP UE ID explicitly for clarity
- Remove RNTI from E1 messages, E1 does not know what an RNTI is

Fix multiple PDUSessions after review, now DRBs are configured sequentially, no matter what PDUSession id we receive