bugfix: nr-ue: set first_tx=1 at first transmission of a harq process

There is a bug that this MR attempts to fix.

The bug is as follows: the UE does Random Access, sends Msg3, but does not receive Msg4. After that it starts Random Access again, and sends a new Msg3 (created by upper layers, MAC and above).

But it uses HARQ process 0 again and in the file openair1/PHY/NR_UE_TRANSPORT/nr_ulsch_coding.c in the function nr_ulsch_encoding() the following tests fail:

  if (harq_process->first_tx == 1 ||
      harq_process->ndi != ulsch->pusch_pdu.pusch_data.new_data_indicator) {  // this is a new packet

And so the old data for the previous Msg3 is sent instead of the new one (which crashes the gnb as of develop

An easy way to trigger this bug with rfsim is to apply this little hack:

diff --git a/openair2/LAYER2/NR_MAC_UE/nr_ue_procedures.c b/openair2/LAYER2/NR_MAC_UE/nr_ue_procedures.c
index 66c86ca4b9..9561fa13fb 100644
--- a/openair2/LAYER2/NR_MAC_UE/nr_ue_procedures.c
+++ b/openair2/LAYER2/NR_MAC_UE/nr_ue_procedures.c
@@ -3714,6 +3714,7 @@ void nr_ue_process_mac_pdu(nr_downlink_indication_t *dl_info,
              }
            }
          }
+          ra_success = false;
 
           if ( (ra->RA_active == 1) && ra_success) {
             nr_ra_succeeded(module_idP, gNB_index, frameP, slot);

The real solution is to deal with what the 3GPP MAC specification 38.321 calls "flush the HARQ buffer" (if I understand correctly). Reading the MAC code for the UE, this solution seems complex to implement.

A simpler solution may be possible though. When we copy data to the a buffer of a HARQ process, we can assume that it's a new transmission, no? So we can for example set first_tx to 1. This is the simple solution that this MR implements.

My analysis may be wrong, it's a proposal.