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

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".

For the reestablishment, we need to tell the PDCP it needs to reset the
SN counters. This does not work over E1; add a TODO in the code.

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Integration Branch 2023.w42

See merge request oai/openairinterface5g!2403

* !2368 NR UE SRB0
* !2399 build_oai: Auto-detect if terminal supports colors
* !2398 Correctly load channel models
* !2365 Change PDU_Length and tlv length calculation to be inline with SCF 222.10.02
* !2402 chore(ci): enabling the ARM cross-compilation pipeline
* !2397 fix(ci): improve for parallelism issue in Groovy
* !2405 Clean IDE files and remove old documentation

  * properly formatted the finalizeSlaveJob function
  * explained the reason and gave an explicit name to the global variable
Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

This enables build_oai to detect if the output terminal supports colors.
If it does, it will use colors in its output. If it does not, it will
just print the text, without color codes, improving legibility.