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?

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/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_ue.c
	targets/RT/USER/lte-softmodem.c
	targets/RT/USER/lte-ue.c

The code was changing the rnti in the red-black tree without
removing/reinserting the context. This is wrong because the
rnti is a key of the red-black tree and you cannot change the
key in a stored item at will.

There are also modifications of the function mac_eNB_rrc_ul_failure
which has to remove the UE in any case.

And rrc_mac_remove_ue has been changed for the case where
the UE is not found.