The oldest PID (the PID that was used the longest
TTI ago) is at the head and is the next one that
will be used.

No test is done to check that when a process is
allocated it is at least N TTIs old, but some quick
thinking strongly leads to the 'conclusion' that N
won't be smaller than 8, which seems to be what
cat3 UEs require to function properly in the downlink
direction (from the eNodeB to the UE).

The problem seems that we reuse HARQ processes too early.
For example, at subframe 0 we allocate PID 0. At subframe 4
we receive an ACK. At subframe 5 we may well reallocate this
PID. It seems category 3 UEs don't like that. They expect
some delay. How much? I don't know. 8 maybe, as for UL.

This commit forces allocation of HARQ PID:
  0 on subframe 1,
  1 on subframe 2,
  2 on subframe 3,
  3 on subframe 4,
  4 on subframe 6,
  5 on subframe 7,
  6 on subframe 8,
  7 on subframe 9.

We don't use subframes 0 and 5 (for initial transmission at
least). (Current develop branch doesn't either I think.)

This is not a good solution, just a quick and dirty one. With this
commit I can achieve 12Mbps with iperf UDP on a 5MHz band 7 carrier
with a cat3 UE. And more than 11Mbps with iperf TCP. And a bad
radio link.

We may want to implement some sort of free-list and take the
oldest PID in there, if it is older than let's say 8 subframes
(that is: the last transmission with this pid was done more
than 8 subframes ealier). We may well have no free PID if a
lot of retransmissions are done.

Merge branch 'feature-34-test_framework' of https://gitlab.eurecom.fr/oai/openairinterface5g into feature-34-test_framework

Merge branch 'develop' of https://gitlab.eurecom.fr/oai/openairinterface5g into feature-34-test_framework

adding error checks in dlsim

Merge branch 'master' of https://gitlab.eurecom.fr/oai/openairinterface5g into feature-34-test_framework