Remove Lombok from several Parameters classes

[Avery-Dunn]

This PR begins the process of removing org.projectlombok.lombok, #909

Lombok is used to generate a lot of boilerplate code, such as getters/setters, builders, and constructures. Removing it all at once would produce a large number of changes which would be hard to review, so this first PR keeps it focused by only removing Lombok from a few similar classes as an example of how follow-up PRs will look.

This PR makes the same basic changes to each file:

• Replace @Getter and @Setter annotations with the actual getter/setters
  • Relatedly, removes the @Accessors(fluent = true) annotation, which simply made the generated getter/setters names exactly the same as the fields (as an example, the getter for the scopes field was scopes() instead of getScopes())
• Replace @Builder with an inner builder class
• Replace @NonNull with our own ParameterValidationUtils.validateNotNull() to ensure certain parameters are not null
• Move Javadoc comments from the private fields to the public builder methods
  • Lombok would copy the Javadocs on private fields to the generated public methods, but in basic Java that doesn't happen
  • Moving them to the builder methods will allow them to still be easily found by developers, such as in tooltip windows in IDEs, and still be clear on automated API doc sites such as https://javadoc.io/doc/com.microsoft.azure/msal4j/latest/index.html

And finally, while removing Lombok we must ensure that no breaking changes are made to any public API. To accomplish that, the RevAPI plugin was used alongside normal testing to ensure the new methods had the same name and the same scope.

[bgavrilMS]

@Avery-Dunn - is there value in reviewing these changes ? I.e. did you de-lombok all of this, in which case it's generaetd code and we can take it at face value?

[Avery-Dunn]

For this first PR, yes:

• Helps to understand what Lombok was doing, and what effects removing it will have
• Demonstrates what the Lombok plugin will produce and confirms it's correct
• Shows what still needs to be manually adjusted, mainly the comments used in API docs

Going forward I don't think so. The next PR will affect a lot more classes, but as long as there are no API changes (as confirmed via RevAPI) and tests pass then it shouldn't require any sort of deep review.

[bgavrilMS]

What is the argument for removing lombok? I thought Lombok generates this code at compile time?

[billwert]

Couple things motivated the ask: 1) Lombok needs plugins in IDEs to make the experience reasonable and 2) the debugging experience can be pretty frustrating.

@JonathanGiles any additional thoughts?

[JonathanGiles]

Lombok is also not an official Java annotation processor, in the sense that is does not uses public APIs exposed by the Java compiler. This is risky and may be broken at any time. It feels bad to build such critical library code on such a weak foundation, especially when the code being generated by Lombok can easily be written by us (or our IDE) once, without these concerns in perpetuity.