Sync checkstyle config with upstream google_checks.xml

[sercuzz8]

Purpose

Update storm_checkstyle.xml to follow Google conventions google_checks.xml
There is no strong rationale but I saw it was originally used as a base.

Changes:

• Splits OperatorWrap into OperatorWrapNL/OperatorWrapEOL so lambdas get upstream's dedicated EOL wrap rule.
• Adds the missing BoxComments variant of TodoComment, catching box-like repetitive comment banners (e.g. // ====...).
• Tightens the IndentationCheck suppression regex to upstream's anchored form.

Not in Google checkstyle:

• Added NewlineAtEndOfFile to follow POSIX's line definition.

Tests and Implementation

1. mvn -pl storm-checkstyle install -DskipTests to rebuild the shared ruleset artifact.
2. mvn validate across the full reactor (OK with BUILD SUCCESS or 0 Checkstyle violations / KO warranted code correction on interested lines until OK).

[reiabreu]

@Gianluca Graziadei You started this one: #8585
I would like to hear your thoughts on this one

[GGraziadei]

Hi @sercuzz8, thanks for your effort and for driving this initiative!
To summarize where we stand on this issue apache/storm#8585 (comment), @sigee outlined the upgrade steps:

• Steps 1 and 2 (Completed): Bumped Checkstyle and set the non-compliant rules to warning.
• Step 3 (Current): Resolve the remaining warnings module by module ( via separate PRs per module to keep code reviews manageable).
• Step 4 move back the warning in errors

That said, fixing these rules manually module by module can become quite tedious. I want to make sure your time and effort deliver the highest possible value to both you and the project.
With that in mind, what would you think about exploring an automated approach alongside or before this?
For example, configuring a Maven plugin could auto-fix many of these checkstyle warnings across the whole codebase in one go, preventing future technical debt altogether.

Either way, it's your call. Once we resolve the module warnings, we can consider aligning our checkstyle rules with the upstream Google manifest. When you're ready for that step, please open a proposal thread on dev@ first so we can gather community consensus.

What do you think?

[sercuzz8]

Hello @GGraziadei,
I agree with this solution, I saw that the issue was already well defined and I went with it but IMO this is better long-term.
I will sketch a solution before proposing this to the community to shorten possible delays.
Thank you for your attention and your advices

[sigee]

I agree with @reiabreu about the python change, besides that LGTM

[sercuzz8]

Update: py change was uploaded in a different PR. Branch for this PR has been rebased with master

[reiabreu]

@sercuzz8 @GGraziadei just touching base on this one.
Are you happy with the status of it so we can proceed with merging?

[rzo1]

Think we can go with it but might need a rebase to avoid breaing the build after the merge marathon today.

[GGraziadei]

Hi, LGTM!

I’d just recommend merging upstream/master beforehand to make sure that any changes in the meantime don’t cause the checkstyle build to fail.