5ms by default, easy to change (change the 10 in the loops)

if the behavior is worse than before, do git revert [commit ID]

Merge branch 'enhancement-10-harmony' of https://gitlab.eurecom.fr/oai/openairinterface5g into enhancement-10-harmony

Merge branch 'enhancement-10-harmony' of https://gitlab.eurecom.fr/oai/openairinterface5g into enhancement-10-harmony

Conflicts:
	targets/PROJECTS/GENERIC-LTE-EPC/CONF/enb.band7.tm1.usrpb210.conf

Merge branch 'enhancement-10-harmony' of https://gitlab.eurecom.fr/oai/openairinterface5g into enhancement-10-harmony

Result of testing as eNodeB. modifications for .vcd logging, bugfix in eNB_thread_FH (subframe counter), update of .conf file for new threading parameters. Updates to gtkwave configuration file for new threading.

Conflicts:
	openair1/SCHED/phy_mac_stub.c
	openair1/SCHED/phy_procedures_lte_eNb.c
	targets/RT/USER/lte-softmodem.c

Merge branch 'enhancement-10-harmony' of https://gitlab.eurecom.fr/oai/openairinterface5g into enhancement-10-harmony

Conflicts:
	openair1/PHY/defs.h
	targets/RT/USER/lte-enb.c
	targets/RT/USER/lte-softmodem.c

Merge branch 'enhancement-10-harmony' of https://gitlab.eurecom.fr/oai/openairinterface5g into enhancement-10-harmony

Conflicts:
	openair1/SCHED/phy_procedures_lte_eNb.c

This was causing oaisim to fail way too often at the startup
of a connection.

Things should go better with this patch.

It may not be the end of the story, the use of retrans_num_bytes_to_retransmit
is not clear to me. The problem I see is: what if the max number of
retransimission has been reached (if that has a meaning at all in RLC AM)?
will this value be decreased or not?