[feat] Add gerrit report configuration options

[panicking]

Make the gerrit review labels and quality gate configurable

The gerrit output voted -1 on both Code-Review and Verified whenever a
report was found, so a change which only introduced a STYLE or a LOW
severity issue was rejected by the pipeline in the same way as a change which
introduced a critical issue. Reporting an issue and rejecting a change are
two different decisions, and only the first one should always happen.

The labels themselves were hard-coded as well: their names, their vote values
and the tag of the review could not be changed. A review could not be sent
without votes, and a project which does not use one of the two labels — or
does not permit the CI user to vote on it — could not use this output at all,
because Gerrit rejects the whole review, including its comments, if any of
the votes in it is not permitted.

Configuration

Three new environment variables control the review, next to the existing
CC_REPO_DIR, CC_REPORT_URL and CC_CHANGED_FILES:

Variable	Meaning	Default
CC_GERRIT_LABELS	Comma separated list of the labels to vote on. The vote values used on failure and on success can be given after a slash. An empty value sends the reports as comments without any vote.	Code-Review=-1/1,Verified=-1/1
CC_GERRIT_FAIL_ON_SEVERITY	The lowest severity level which makes the review fail: UNSPECIFIED, STYLE, LOW, MEDIUM, HIGH or CRITICAL.	unset — any report fails the review
CC_GERRIT_TAG	Tag of the review.	jenkins

Example for a review which reports everything but only rejects a change for a
high severity issue, and which abstains from Code-Review instead of
approving the change:

export CC_GERRIT_LABELS="Verified=-1/1,Code-Review=-1/0"
export CC_GERRIT_FAIL_ON_SEVERITY="HIGH"

Changes made

• The reports and the votes are decoupled. Every report is still sent as an
  inline comment, but only the reports at or above
  CC_GERRIT_FAIL_ON_SEVERITY result in a negative vote. Minor findings are
  therefore visible in the review without failing the quality gate.
• The message of the review shows the outcome of the gate, e.g.
  CodeChecker found 3 issue(s) in the code. 1 of them are at or above the 'HIGH' severity. or ... None of them are at or above the 'HIGH' severity., and it tells the reviewers when no vote was cast at all.
• The labels to vote on, their vote values and the tag of the review are
  configurable. A label which is not listed is not sent, so the reports can
  be published without any vote.
• The new variables are validated before the conversion. Both
  CodeChecker parse -e gerrit and CodeChecker cmd diff -o gerrit already
  call mandatory_env_var_is_set() before doing any work, so an invalid
  severity level or a malformed label results in an error message instead of
  a silently different review.
• Unit tests cover the configurable labels, the vote values, the report-only
  mode, the severity gate (including reports without a severity) and the
  validation of the environment variables.
• The new variables are documented in the help output of CodeChecker parse
  and CodeChecker cmd diff, in docs/web/diff.md and in the Jenkins
  integration guide, whose example build script sets them.

Compatibility

If none of the new variables is set, the generated review is identical to the
previous one, and so is the message. In this case a warning is logged which
points to the new configuration.

Testing

• The gerrit unit tests of the report-converter
  (pytest tests/unit/output/gerrit): 18 passed, including the 4
  pre-existing tests which pin the legacy behaviour of the output.
• mypy --ignore-missing-imports codechecker_report_converter, pylint
  with the repository .pylintrc and pycodestyle on the modified Python
  files — clean.
• The functional tests which also exercise this output
  (analyzer/tests/functional/analyze_and_parse,
  web/tests/functional/diff_local_remote) were not run locally, they need
  a full CodeChecker build.

Known limitation

The exit code of CodeChecker cmd diff and CodeChecker parse is 2 when
there is any report difference, independently of this quality gate, so a
Jenkins build step still fails for a change with only minor findings. A A
severity aware exit policy is a possible follow-up, this change only affects
what is sent to Gerrit.

Commits

1. [feat] Make the gerrit review labels and tag configurable
2. [feat] Add severity based quality gate to the gerrit output
3. [doc] Document the gerrit output environment variables in the CLI help
4. [doc] Describe the gerrit labels and quality gate in the Jenkins guide