Checkstyle: LineLength max 165, AnonInnerLength 45 and other whitespace checks

[ham1]

Also removed some unnecessary StringBuilders

How Has This Been Tested?

ant checkstyle test

[codecov-io]

Codecov Report

Merging #358 into trunk will decrease coverage by <.01%.
The diff coverage is 40.92%.

@@             Coverage Diff              @@
##              trunk     #358      +/-   ##
============================================
- Coverage     58.37%   58.37%   -0.01%     
- Complexity    10316    10317       +1     
============================================
  Files          1170     1170              
  Lines         74347    74411      +64     
  Branches       7324     7326       +2     
============================================
+ Hits          43399    43435      +36     
- Misses        28421    28451      +30     
+ Partials       2527     2525       -2

Impacted Files	Coverage Δ	Complexity Δ
.../org/apache/jmeter/report/core/SampleMetadata.java	26.08% <ø> (ø)	8 <0> (ø)	⬇️
...jmeter/protocol/http/util/accesslog/LogFilter.java	81.3% <ø> (ø)	35 <0> (ø)	⬇️
...protocol/http/sampler/LazySchemeSocketFactory.java	66.66% <ø> (ø)	5 <0> (ø)	⬇️
...ter/extractor/json/jsonpath/JSONPostProcessor.java	66.95% <0%> (ø)	28 <0> (ø)	⬇️
...jmeter/visualizers/backend/BackendListenerGui.java	80.37% <0%> (ø)	13 <0> (ø)	⬇️
.../org/apache/jmeter/engine/util/FunctionParser.java	69.35% <0%> (ø)	33 <0> (ø)	⬇️
...he/jmeter/visualizers/backend/BackendListener.java	10% <0%> (-0.29%)	7 <0> (ø)
...er/protocol/http/proxy/AbstractSamplerCreator.java	60% <0%> (+0.62%)	6 <1> (ø)	⬇️
...e/org/apache/jmeter/gui/action/OpenLinkAction.java	0% <0%> (ø)	0 <0> (ø)	⬇️
...apache/jmeter/control/gui/ModuleControllerGui.java	31.25% <0%> (ø)	8 <0> (ø)	⬇️
... and 37 more

---

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 33f09a9...7535a0c. Read the comment docs.

[pmouawad]

Hi @ham1 ,
Thanks for this PR.
Unfortunately I am not very comfortable with PR that touch a lot of file and where the code modification may touch more things than what the PR describes.

Would it be possible to rebase your PR and split it into at max 10 files ?
It is easier to review and merging is faster for me, which will mean I'll merge it earlier and you won't have to rebase.

Also if possible, try to make the PR really only touch what it pretends to.
Sonar fixes might sometimes break existing code so they need careful review and merge.
Thanks a lot again for all your work !

Regards

[ham1]

Sorry, yeah I see how this is difficult to review. I tend to change things as I see them in the file I'm editing. I will revise and split it up into one type of change per commit, is that ok? It might be more than 10 files but should be easier to review.