Avoid static imports and add the related checkstyle

I think that sometimes the code is not so readable using static imports. An example is here using just sigleton which seems not to be clear coming from Collections but could be a private method in the class. Of course, using an IDE you have all the facilities to get that but it’s not the same while reviewing on GitHub. As mentioned by @tombentley I would propose to avoid using static imports and adding the related checkstyle https://checkstyle.sourceforge.io/config_imports.html#AvoidStaticImport. It’s more a refactoring work.

Of course, it’s possible that my opinion is not commonly shared with the other @strimzi/maintainers so if Tom is ok to stick with static imports, what the others think?

[samuel-hawker]

I think in general static imports should be allowed in test code. Maybe not so in non-test code? with certain ModelUtils exceptions.

[samuel-hawker]

I quite like allowing static imports for HamCrest matchers as

assertThat(actual, is(expected))

is better than

Matchers.assertThat(actual, Matchers.is(expected))

Since matchers are always nested inside assertThats i see no ambiguity as to which class they came from.