- remove iperf directions, use iperf3 for all tests
- use ci_infra to get server IP and command prefix
- cleanup

Integration: 2023.w51

See merge request oai/openairinterface5g!2483

* !2221 NR UE going to IDLE state
* !2464 move common .h file in common directory, remove mem_block_t
* !2479 CI: test with 2 UL layers in AW2S pipeline
* !2468 LDPC T2 card: fix and doc update
* !2480 Enabling multi-ue support in the open-source L2 proxy
* !2476 Fixes for multi-DU/CU-UP and CI test
* !2482 Trigger UL Failure if Ack of Msg4 not received
* !2484 function to harmonize handling of NAS registraction accept

- for F1U, F1C, E1, UE and Core
- update README with subnets
- better document sample output

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.

- set size of buffers to max E
- change HARQ codeblock offset calculation for T2
- add constant for maximum code block size - max E

MR-2401 changed the argument to the init_nrUE_standalone_thread
to be zero instead of the ue_id_g. This causes every port to be
opened for multiple UEs to have the same value, therefore only
allowing one UE to be connected to the proxy. If the ue_id_g
global is an issue, we should open a new ticket for a proper fix.

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