Merge branch 'NR_RRC_harq_hacks' of https://gitlab.eurecom.fr/oai/openairinterface5g into NR_RRC_harq_hacks

Merge branch 'NR_RRC_harq_hacks' of https://gitlab.eurecom.fr/oai/openairinterface5g into NR_RRC_harq_hacks

Merge branch 'NR_RRC_harq_hacks' of https://gitlab.eurecom.fr/oai/openairinterface5g into NR_RRC_harq_hacks

Merge branch 'NR_RRC_harq_hacks' of https://gitlab.eurecom.fr/oai/openairinterface5g into NR_RRC_harq_hacks

Merge branch 'NR_RRC_harq_hacks' of https://gitlab.eurecom.fr/oai/openairinterface5g into NR_RRC_harq_hacks

Develop Integration Branch -- 2020 week 19

The following Merge Requests were included:

* MR [810] : NR PUCCH
* MR [812] : fix 20 compilation warnings
* MR [815] : rlc v2 -- coverity scan fixes
* MR [816] : hotfix: fix compilation of UE with --musim

Also add fixes for CI

The following was failing:
./build_oai --UE --musim

Not sure this fix is correct, but it seems consistent with
the rest of platform_constants.h.

Merge branch 'NR_RRC_harq_hacks' of https://gitlab.eurecom.fr/oai/openairinterface5g into NR_RRC_harq_hacks

Merge branch 'NR_RRC_harq_hacks' of https://gitlab.eurecom.fr/oai/openairinterface5g into NR_RRC_harq_hacks

Minor fixes, doesn't change anything. Not sure these are 'bugs' either,
but let's be polite with coverity scan...

One thing was not changed.
Coverity scan says:
*** CID 357991:  Memory - illegal accesses  (USE_AFTER_FREE)
/home/carabe/raphael/openairinterface5g/openair2/LAYER2/rlc_v2/rlc_entity_am.c: 507 in tx_list_remove_sn()
501         } else {
502           prev = cur;
503           cur = cur->next;
504         }
505       }
506
>>>     CID 357991:  Memory - illegal accesses  (USE_AFTER_FREE)
>>>     Using freed pointer "head.next".
507       return head.next;
508     }
509
510     void cleanup_sdu_list(rlc_entity_am_t *entity)
511     {
512       rlc_sdu_t head;

But as far as I understand, there is no problem. We don't access
head.next at all if it has been freed. Or is there some aliasing
going on there (pointer aliasing)? I doubt it. False positive?

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

-- check if C file has a GNU GPL license
-- check if C file has s suspect license
-- check if C header is having correct circular dependency protection (with Laurent Thomas's help)
Signed-off-by: Raphael Defosseux <raphael.defosseux@eurecom.fr>

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

  - The number of nb_dmrs_re at gNB side was set to 6, but here it is assumed
    that there will be no data allocation in OFDM symbols that carry DMRS
  - nb_dmrs_re that is being given as an input to the TBS calculation,
    should be multiplied by the number of DMRS symbols in order to get the total
    number of DMRS REs per RB
  - In the calculation of G, only the number of DMRS per RB in 1 OFDM symbol should
    be given as an input, because inside the function of the G calculation, this
    number is being multiplied by the number of OFDM symbols that carry DMRS