When there is a retransmission, we want to use the same number of RBs.

The RBs are allocated by groups (RBGs).

In some cases (like a cell with 25 PRBs), the last RBG contains less RBs.
So in case of a retransmission, if this last RBG was used before we need
to reuse it to have the same number of RBs. If not, we will use more RBs
for the retransmission than the previous transmission.

In an experiment with two UEs (quectel modules) it was seen that when a
retransmission happens with a different number of RBs then the UE is not
happy at all, leading to way more NACKs in the harq processes than should
happen (actually the first NACK was not a NACK at all, but the eNB did
interpret it as a NACK; so the next transmission should simply be discarded
by the UE that successfully received the first transmission; instead the UE
fails to decode the data and sends a NACK, a real one this time).

Maybe it's not the correct solution, but it improve things, there are
much less NACKs.

OTA testing 4G, configuration parameters for fairRR scheduler and common parameters for both fairRR and default

This commit contains work done by Eurecom and by Benetel.

Selects the UE with the highest CQI. If two UEs have the same CQI,
choses the one with highest number of bytes in RLC queue. Allocates as
many RBGs as possible, and potentially continues with the next UE.

Selects UE with highest coefficient. Allocates until there are no more
RBGs to allocate, or UE has no more data. In the latter case, continues
with the next UE (second-highest coefficient).

- Loop only to next UE instead of jumping multiple

- mark used RBGs in rbg_mask

- Only calculate number of RBs based on CQI when UE is selected, instead
of calculating for all UEs which might be unnecessary.

- When looping the list of UEs for RB allocation, remove UEs that have
no data anymore instead of skipping them.

hack: in schedule_ue_spec, 3 bytes are "reserved" (this should be
done better). An RLC AM entity may ask for only 2 bytes for
ACKing and get a TBS of 32 bits and due to these 3 reserved bytes we may
end up with only 1 byte left for RLC, which is not enough. This hack
prevents the problem. To be done better at some point. If the function
schedule_ue_spec is (has been) reworked, this hack can be removed.
Dig for "TBS - ta_len - header_length_total - sdu_length_total - 3"
in schedule_ue_spec.

This should be done better at some point.

Selects the UE with the highest CQI. If two UEs have the same CQI,
choses the one with highest number of bytes in RLC queue. Allocates as
many RBGs as possible, and potentially continues with the next UE.

Selects UE with highest coefficient. Allocates until there are no more
RBGs to allocate, or UE has no more data. In the latter case, continues
with the next UE (second-highest coefficient).

- Loop only to next UE instead of jumping multiple

- mark used RBGs in rbg_mask

- Only calculate number of RBs based on CQI when UE is selected, instead
of calculating for all UEs which might be unnecessary.

- When looping the list of UEs for RB allocation, remove UEs that have
no data anymore instead of skipping them.