Remove unnecessary return statements on lambdas and encapsulate public fields with fluent accessors

[bmscomp]

The purpose of this pull request is to bring some practices for reducing the number of lines on a growing class, and apply some practices, with some formatting to make it more readable and less verbose, notice that the maven formatter plugged into the project is used to ensure the conformity of the formatting

• remove non necessary return statement on some lambdas
• replace a check of instance of by non nullable check
• remove duplicated cast for List<?>
• encapsulated directly accessed public fields with fluent accessors

[kdubb]

IMO, many of these changes make the code less readable. There doesn't seem to be any advantage to replacing these single statement blocks with expressions, except to push the code 4-8 spaces to the right.

[bmscomp]

@kdubb thanks so much for the review, I agree the pull request is too minimal and it contains only a remove of the duplication and the nullability check instead of instance of but I can make it rich by updating it with other related topics, for examples the RoleOptions class that contains the contains all attributes as public and accessors that are not used, I can bring some encapsulation to it,

Please let me know what do you think about that ?

[bmscomp]

@kdubb I updated the pull request to add a final keyword to a field in class and of course encapsulate fields SignIntermediateCAOptions.java and I used fluent accessors, as java suggest for records, to prevent non used methods

[kdubb]

The biggest piece of this PR is source breaking and cannot be implemented without a major version bump. Additionally, the other "options" classes in the API are implemented similarly so we'd be changing just one of them, not all.

Finally, a point of personal preference (seemingly shared by @vsevel), there is no advantage to adding encapsulation to fields with public getters/setters for very simple classes like these "options" classes. Yes there can be advantages when the class/object will be long-lived or needs to interface with an API expecting a "bean". These objects are very transient and 99% of the time only live as long as a single function call.

I'm not sure this is something we need to tackle now or in the future.

WRT other changes. There are some documentation fixes that could be moved into another PR, which would be helpful.

[kdubb]

This is a public class. We can't make this change without breaking all existing code.

[kdubb]

This is mostly implemented in #215 and the anyhting else is quite of out-of-date because of that PR.