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

Conflicts:
	openair2/LAYER2/NR_MAC_COMMON/nr_mac_common.c

fixed issue related to scheduing of PRACH for long sequence (only gets done in last slot of subframe now, not both) and start point of DFT in RU processing for long-sequence. Removes fatal segfault.

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>