Fix usrp_lib for threequarter sampling

See merge request oai/openairinterface5g!732

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Integration develop nr 2019w48bis

See merge request oai/openairinterface5g!729

Signed-off-by: Prateek Bidwalkar <prateek.bidwalkar@ipaccess.com>

Signed-off-by: Prateek Bidwalkar <prateek.bidwalkar@ipaccess.com>

Develop nr fix multi rru

See merge request oai/openairinterface5g!722

Nr channel estimation and other fixes

See merge request oai/openairinterface5g!714

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

Integration develop nr 2019w46

See merge request oai/openairinterface5g!716

Merge remote-tracking branch 'origin/fix-nr-rfsim-gNB-notx-slots2to19' into integration-develop-nr-2019w46

Merge branch 'nr-channel-estimation' of https://gitlab.eurecom.fr/oai/openairinterface5g into nr-channel-estimation

In 3/4 sampling mode, the OFDM symbol size is _not_ a power of two (e.g. 1536 instead of 2048).
In this case it is _not_ OK to calculate the modulus using a binary AND, it _must_ use either the actul modulus operator (%) using an integer division,
or a _correct_ if statement or tertianary operator like this:

re_offset = (re_offset + 4 >= ue->frame_parms.ofdm_symbol_size) ? (re_offset + 4 - ue->frame_parms.ofdm_symbol_size) : (re_offset + 4);

But of course using the actual modulus operator is much more readable and surely not much slower:

re_offset = (re_offset + 4) % ue->frame_parms.ofdm_symbol_size;