NIFI-12573 Improve support for Enum values in PropertyDescriptor.Builder

[EndzeitBegins]

Summary

NIFI-12573
Lowers type restrictions on three methods in PropertyDescriptor.Builder to allow to work with DescribedValue instead of child class AllowableValue and with both Enum classes that do and do not implement DescribedValue.

Also addresses NIFI-12574 by adding a new method clearDefaultValue to PropertyDescriptor.Builder.

Adds several test cases for the affected code.

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using mvn clean install -P contrib-check
  • JDK 21

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[exceptionfactory]

Thanks for the contribution @EndzeitBegins. Supporting any enum would follow a similar pattern to the existing methods that take a set of strings. Is there any other particular reason prompting these changes? In the course of new implementations, providing an enum that implements DescribedValue is always preferred because it requires methods for display name and description.

[EndzeitBegins]

Thanks for the questions @exceptionfactory.
First of all I agree that it should be preferred to let the enums implement DescribedValue whenever feasible.
Maybe that's something worth to better highlight in the code documentation.

In particular I thought about two situations, where the more adaptive approach introduced in this PR would be beneficial.

1. There might be cases we're an existing enum (e.g. from a library) is used that cannot be altered. Even though I'd personally prefer creating one's own enum (implementing DescribedValue) that maps to the library one (similar to the azure bundle) I can see how someone might not want to go "the extra mile". A user can use that Enum as allowableValues more easily now.
2. And by far more important to me, I noticed that when using the existing public <E extends Enum<E>> Builder allowableValues(final E[] values) with an enum that actually implements DescribedValue, those values will be ignored, which might come as a surprise. I wouldn't want to restrict the Enums to implement DescribedValue here, as that would be quite a large breaking change. That's why I thought aligning the behaviour of all Enum based methods would be beneficial for ease of understanding.

[exceptionfactory]

Thanks for the quick reply @EndzeitBegins. That's a very good point about the second scenario, and the first one is also reasonable. With that background, I agree with the changes and will proceed with merging. +1

[EndzeitBegins]

As always, thank you for input and taking on the merge process @exceptionfactory. 🙂👍🏻