Develop Integration 2020 week 23

The following merge requests have been included:

* MR 823 : NR-UE Init sync bugfix
* MR 824 : code cleanup

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

Develop Integration Branch : 2020 week 22

The following Merge Requests are been included:

* MR 796 : Nr rrc configuration trx thread
* MR 807 : Use SCF FAPI for DMRS and PTRS also on UE side
* MR 817 : Fixing errored/missing circular dependency protection
* MR 819 : cleanup branch and initial ninja build support
* MR 820 : CI: Add OAI-CN-In-Docker support

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>

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

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

Merge remote-tracking branch 'origin/add_oai_cn_docker_support_to_ci' into develop_integration_2020_w22

Merge remote-tracking branch 'origin/fix-circular-dependency-protection' into develop_integration_2020_w22

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

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

Conflicts:
	ci-scripts/epc.py

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

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.

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>