changes for ulsim to get functionality back. simulation behaviour for PUSCH is not good (BLER waterfall is way too steep even if SNR threshold is ok). Note develop does more or less the same thing but SNR threshold is lower.

- IP data were fetched and passed to MAC directly at the PHY layer
- random data was generated whenever there's no upcoming data.
- Therefore these functionalities are now moved to MAC and FAPI interfaces
- are used instead.

- no_data_in_dmrs was being used at gNB side, and not handled at UE side
- nr_schedule_response wasn't being called in ulsim

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

- Apply a value which cannot be interpreted as any valid LCID at the MAC layer of the receiver gNB (as per 38.321 Table 6.2.1-2),
to avoid forwarding the random PDU to the upper layers in noS1 mode.

  - By default this value is equal to 0 at gNB in case of ulsim, but
    has a value in case of RF simulator
  - The N_TA_offset was calculated but not used at UE side

  - By default this value is equal to 0 at gNB in case of ulsim, but
    has a value in case of RF simulator
  - The N_TA_offset was calculated but not used at UE side

   - The bug occurs when the PUSCH allocation contains the central RB of the whole UL BW

ENDC S1-U gNB support: Separate some GTP functions between eNB and gNB. Downlink traffic from SGW arrives properly at gNB now after path switch

Using ul_dmrs_symb_pos at UE side instead of assuming that DMRS is only present at 1st symbol of PUSCH

  - Using the implemented DMRS functionalities at the MAC layer at the gNB side
  - Removing is_dmrs_symbol function
  - Temporary implemetation at the UE side considering DMRS symbol is at the 1st PUSCH symbol,
    until the nFAPI structs for DMRS is adopted at the UE side

rfsim works

an assertion fails in gnb (need to be fixed)