Options:

1. increase limit (like here)
2. create a baseline (skip/suppress this check for existing cases/classes)
3. change existing classes and keep the old property value max limit

From my POV both of these checks are overzealous and hence I turned them off, but I'm open to a discussion.

Related links:

• https://checkstyle.sourceforge.io/checks/misc/finalparameters.html
• https://checkstyle.sourceforge.io/checks/coding/finallocalvariable.html
• https://softwareengineering.stackexchange.com/questions/48413/in-java-should-i-use-final-for-parameters-and-locals-even-when-i-dont-have-t
• https://stackoverflow.com/questions/3635863/why-method-parameters-needs-to-be-set-as-final
• https://stackoverflow.com/questions/500508/why-should-i-use-the-keyword-final-on-a-method-parameter-in-java
• https://www.reddit.com/r/learnjava/comments/1ffoa9p/using_final_in_method_parameters_your_opinion

I didn't pay attention to this PR, but upgrading a dependency should not change any checkstyle rules... We should not have disabled this; inside KS module, we have this rule for a long time, and want to keep it (personally, I would think it would actually be good to even expand its scope to the entire code base, but that's a different discussion, and I don't want to touch it at this point)

Fixing via #21456

\cc @chia7712

Options:

1. increase limit (like here)
2. create a baseline (skip/suppress this check for existing cases/classes)
3. change existing classes and keep the old property value max limit