The 5G-RFsim F1 test tested multiple DUs at one CU. This
functionality is retained in the new F1+E1 test.

The 5G-RFsim E1 test tested a single CU-UP at a single CU-CP.  Here, we
extend to use multiple CU-UPs, one for each DU. The associated is
ensured by using three different F1-U transport networks, one for each
DU/CU-UP pair.

- Test only one DU at the CU (3 DUs is tested in F1+E1)
- Harmonize IP configuration to make it simpler to reuse in the F1+E1
  test
- Speed up the test by reducing the number of steps to deploy core/RAN
- Add traffic test

binding the local address for SCTP is pointless, because we don't really
care through which interface SCTP traffic goes. Actually, we even might
want to set the DU remote_n_addr and the the local_n_addr to addresses
in different networks, because we might want to have GTP traffic go
through a different interface than SCTP, as done in the CI test for E1.

We set the RFsim TCP socket to non-blocking. Thus, it may happen that we
cannot write() to the socket when the kernel cannot handle the request,
in which case we wait some time before trying again. This is the
correct/expected behavior.

Since this is *normal*, an error message is not justified; we did not
even print a message in this case before commit 21790f9c introduced it.

Additionally, initialize the F1AP PDU to zeros

When setting up bearer(s) through F1, the corresponding F1 message has
QoS fields for the DRB(s) to be set up, as well as for all flows
associated to this DRB. In this commit, set the DRB QoS field to be
equal to the first flow (it is unclear/unspecified how it should be set
up, based on the flows), which was not set before and therefore
contained unitialized data.

The F1 module uses this data, and in split mode, F1 message generation
failed due to uninitialized data.

The allowed NSSAIs is NOT the NSSAI to be used for a UE. Fix it to use
the correct one.

We reuse RRC UE IDs at the RRC. Previous to this commit, we did not
release a UE at the CU-CP's PDCP (for SRBs). Thus, when reconnecting a
UE, the PDCP might not be in a good state, since we did not release the
previous PDCP UE context.

Integration: 2023.w50

See merge request oai/openairinterface5g!2474

* !2460 bugfix: initialize TX and RX antennas separately
* !2471 fix a useless computation done in case we activate LOG_D
* !2417 PDSCH precoding optimization
* !2436 Fix the DoS vulnerability in RA procedure
* !2472 (ci): adding new packages in cuup dockerfiles
* !2463 NR UE RRC MAC configuration improvements
* !2475 Fix gNB RA procedures when Msg4 Ack not received

Merge remote-tracking branch 'origin/NR_UE_MAC_configuration_further_improvements' into integration_2023_w50

When the gNB does not receive PUCCH with Ack for Msg4 we have to consider Msg4 received by the UE, so we need to apply the CellGroupConfig sent to the UE.
There are two scenarios:
1 - The UE never decoded PDSCH for Msg4, the RA will fail because RA Contention Resolution timer, the UE will come with a new RA with new RRCSetupRequest
2 - The UE decoded PDSCH for Msg4, and if SR does not work and no resources for PUSCH, it will trigger RA with MAC CE C-RNTI in Msg3 (so, gNB must be ready for it)

Merge remote-tracking branch 'origin/fix-dos-vulnerability-of-RA-procedure' into integration_2023_w50

The CI machine for these tests is overloaded with many
UEs running at the same time, all using the address sanitizer.

Use blend instead of set and extract to rearrange, faster
Use 256 SIMD for every 2 RB, use 128 SIMD for ARM and last RB

Signed-off-by: okabetakayuki <okabe_takayuki@jp.fujitsu.com>

- Removed rfsim option from cu, cu-cp and cu-up