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.

PDU Length is as per SCF 222.10.02: The total length (in bytes) of the
PDU description and  PDU data, without the padding bytes. From
TX_DATA.request we get 8 (2 bytes PDU_Length + 2 bytes PDU_Index + 4
bytes num_TLV ) and from each TLV we get 4 + value size ( 2 bytes tag +
2 bytes length + value size without pading)

Therefore, add function to compute PDU_length() value for
TX_Data.request, taking into account how many TLVs there are.
compute_PDU_length() does not rely on access to `nfapi_nr_pdu_t`.
Put it into nr_mac_common.c to avoid introducing dependencies.

	modified:   radio/rfsimulator/simulator.c

integration_2023_w41

See merge request oai/openairinterface5g!2394

* !2389 Remove global variable rx_spatial_power
* !2364 NR UE PUCCH2 sanitize errors
* !2352 Break DCI processing function into smaller pieces
* !2391 Remove calloc from L1 at CSIRS_PDU conversion function
* !2393 Fix UE assertion due to PUCCH resource lookup all BWPs
* !2307 Improve documentation for L2sim Readme
* !2310 doc(websvr): how to install properly the dependencies

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