The function generateDRB() sets the value to 100ms but the function
rrc_gNB_process_NGAP_PDUSESSION_SETUP_REQ() sets it to 0ms.

So what happens is that the UE gets the value 100ms in the
RRC Reconfiguration but the gNB creates the PDCP entity with 0ms.
Let's create it with 100ms instead, to be aligned with how we configure
the UE.

And also avoid some PDCP warnings at runtime when some packets
are retransmitted but rejected because of the 0ms timer. This is
the warning:

    [PDCP]   discard NR PDU rcvd_count=68469, entity->rx_deliv 68481,sdu_in_list 0

This is just a hotfix. A real solution is to have the RB creation in
only one place. And we should also have those parameters configurable.
Work for later.

When au UE disconnects, a write on the rf simulator socket may
generate a PIPE signal in the gnb and crash it.

Let's ignore this signal.

Closes #685 and #698

See merge request oai/openairinterface5g!2425

* !2404 NR UE MCS for retransmission v2
* !2420 Scan build: Argument with 'nonnull' attribute passed null
* !2422 Fix AssertFatal when using NR band n1
* !2418 NR UE resynchronization fix
* !2376 Save NSSAI params of PDU session coming from AMF
* add `build_oai` option for thread sanitizer
* update 60 MHz 2x2 phytest-timing threshold
* !2423 Free F1 UE data struct only on UE release
* !2428 Prevent CU-UP UE ID management if integrated CU
* !2390 NR PTRS improvements
* !2291 Pass config object instead of using implicit global
* !2421 Change UL_TTI.request PRACH PDU beamforming pack/unpack handling
* !2406 CI:AW2S - test with 10 AmariUEs
* !2401 ue-rrc-coarse-cleaning
* !2366 Remove F1 BWP switching logic
* !2426 F1: support multiple DUs per CU
* !2432 Remove cblas dependency for 5G targets

- PRACH Configuration Index = 98 is not suSpported by the Amarisoft UE simulator, as a number of PRACH occasions within the PRACH slot is > 1
- for PRACH Configuration Index = 100, number of time-domain PRACH occasions within a PRACH slot is 1

Multiple DUs host cells, whose cell ID cannot match (to identify them
uniquely). Hence, don't check for equality with CU, because otherwise,
we can never connect multiple DUs.

This is a workaround for a problem described in #706. In short, we
cannot reuse the cu_add/remove_f1_ue_data() functions if we are in an
integrated CU-UP/CP ("CU"), but then we can also not reliably use
different UE IDs in CU-UP and CU-CP (except if using even more hacks).