Merge remote-tracking branch 'origin/NR_UE_improve_handling_msg4_feedback' into integration_2023_w47

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

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

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

This commit follows the previous one and adds a dependancy for the
generated .h files so that when we change T_messages.txt to add a
T trace, the compilation succeeds when using ninja in
cmake_targets/ran_build/build.

When using the make system to generate T files, if you change
T_messages.txt you may have problems compiling the gnb with ninja.

If you want to see the problem:
First run: cd cmake_targets; ./build_oai --ninja --gNB
Then: cd common/utils/T
edit T_messages.txt, add a trace, for example:
---
ID = ENB_PHY_UL_TOCK
    DESC = eNodeB uplink tick - one tick per ms at start of uplink processing
    GROUP = ALL:PHY:GRAPHIC:ENB
    FORMAT = int,eNB_ID : int,frame : int,subframe
---
then run: make
then: cd cmake_targets/ran_build/build; ninja nr-softmodem
You should have an error looking like this:
---
[3/81] Checking validity of VCD files
FAILED: common/utils/T/CMakeFiles/check_vcd /tmp/develop/cmake_targets/ran_build/build/common/utils/T/CMakeFiles/check_vcd
cd /tmp/develop/cmake_targets/ran_build/build/common/utils/T && /tmp/develop/cmake_targets/ran_build/build/common/utils/T/_check_vcd /tmp/develop/common/utils/T/T_messages.txt /tmp/develop/common/utils/T/../LOG/vcd_signal_dumper.h
error: VCD_FIRST_VARIABLE is not correct in T_defs.h

You probably added a VCD trace (variable or function) but you did not
update T_messages.txt and/or T_defs.h in common/utils/T/
[...]
---

Let's first isolate the generated T .h files when using make because
we have two versions of T_IDs.h and T_messages.txt.h when mixing
make/cmake.

A next commit will regenerate T_IDs.h and T_messages.txt.h when
T_messages.txt chages for the cmake system, because this commit
does not solve the problem.