Add sonarqube capacities to Ginkgo.

[tcojean]

A long time ago, I tried out using sonarqube with Ginkgo and we got some really
nice code analysis out of it. This small PR adds this capacity to Ginkgo as part of
the CI system. The main goal is to have statistics (coverage, new bugs, etc) for
each pull request before merging into develop. This would allow to take care of
many coding problems as part of the PR process rather than after merging.

After this, I believe Ginkgo is fairly well covered in terms of tools for code static
and dynamic analysis. This is the last tool I wanted to add to Ginkgo.

• Adapt the containers to bundle the sonar-scanner tool when found.
• Add a CUDA job which launches the build-wrapper and sonar-scanner tools to
  scan the code and update all data online.
• Put all coverage analysis on a per branch basis instead of only for the long
  living branches. This provides change metrics for branches before they are
  merged to develop.

[codecov]

Codecov Report

Merging #304 into develop will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #304   +/-   ##
========================================
  Coverage    98.09%   98.09%           
========================================
  Files          216      216           
  Lines        16058    16058           
========================================
  Hits         15752    15752           
  Misses         306      306

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5e0ca65...25231f0. Read the comment docs.

[tcojean]

This PR should now be finished and ready for review. You can see what the PR changes by looking at the bottom of it:

1. There is a codecov report which shows up with a graph of coverage changes (here nothing changes, so it's all grey).
2. There are now 4 checks for each PR, the gitlab pipeline as usual, and after the sonarqube_cov step is processed, three extra checks are added. Two are regarding codecov, and the last one is the sonarqube "quality gate" which becomes red when either:
   1. There is bad coverage for the changes
   2. There is too many code duplication
   3. There are critical bugs (or many small ones) which are added as part of the PR.

Note that, for the sonarqube check to appear, a commit needs to happen to the branch (or the pipeline has to be ran), after the PR has been created on Github. If that is not the case, the analysis will nonetheless be available on sonarqube but will not appear here. In practice, I think there is always a couple of commits in the PR, as request for changes and fixes happen (at least for the big PRs which we want to have the sonarqube check).

[thoasm]

@tcojean Does it also work if I only force-push (overwrite my last commit) after I create a PR?

[tcojean]

@thoasm as long as there is a pipeline trigger in some way and an open PR, this will work.
You could also only trigger a pipeline from the Gitlab.

[thoasm]

@tcojean Then I think this should be fine.

[thoasm]

LGTM!
Interesting tool

[pratikvn]

Really useful tool. But I guess it needs to tweaked a bit to tell what false positives it detects ?

[tcojean]

@pratikvn Yes, you can do it from the web interface and set particular issues as false positive or won't fix. I believe that is the preferred way of controlling this.