MINIFICPP-1077 - Linter shouldn't warn on non-const references

[arpadboda]

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

For all changes:

• Is there a JIRA ticket associated with this PR? Is it referenced
  in the commit message?

• Does your PR title start with MINIFICPP-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

• Has your PR been rebased against the latest commit within the target branch (typically master)?

• Is your initial contribution a single, squashed commit?

For code changes:

• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
• If applicable, have you updated the LICENSE file?
• If applicable, have you updated the NOTICE file?

For documentation related changes:

• Have you ensured that format looks appropriate for the output in which it is rendered?

Note:

Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.

[bakaid]

I agree that we should disable this.

I don't think that the arguments presented for the existence of this warning at https://google.github.io/styleguide/cppguide.html#Reference_Arguments are convincing. The only factual argument is that "References can be confusing, as they have value syntax but pointer semantics", which I don't find very strong, as with minimal care this confusion can be avoided, the other one, that "In fact it is a very strong convention in Google code that input arguments are values or const references while output arguments are pointers" without further elaboration is a fallacy of argument from authority.

Personally, I only like to use raw pointers in C++ when it indicates ownership of a raw resource (malloced memory for example) and use references in all other cases.

Using pointers as output parameters makes code uglier, as acknowledged by the Google styleguide: "Defining a parameter as reference avoids ugly code like (*pval)++."

I don't mind if a particular use case necessitates the usage of pointer output parameters, but I would very much dislike enforcing a policy that would make them mandatory.