NIFI-14491 Support other types in CreateBoxFileMetadataInstance

[awelless]

Summary

NIFI-14491
Adding support for numeric, date and array types in CreateBoxFileMetadataInstance.
Adding support for date type in UpdateBoxFileMetadataInstance.

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

[sfc-gh-rpaulin]

This is a good addition @awelless. Provided a few suggestions but this looks like the behavior a user would expect for each of these types.

[sfc-gh-rpaulin]

Since isNumber is checking up to BigInteger and BigDecimal (arbitrary precision) it's possible that a number larger than double precision will be retrieved. Given box only accepts up to double precision this seems appropriate. Just wanted to make sure we're calling out the preference that we are opting for being more accepting of numbers being rounded or set to positive or negative infinity over throwing an error. Agree with the approach but wanted to call out the design decision.

[sfc-gh-rpaulin]

Might be good to add a large number to demonstrate we are preferring rounding over erroring when numbers requiring more than 64 bits.

[awelless]

Good point. Added a value in the test presenting that scenario

[sfc-gh-ncover]

Suggested change

	return RecordFieldType.DATE.equals(fieldType);
	return RecordFieldType.DATE.equals(fieldType) || RecordFieldType.TIMESTAMP.equals(fieldType);

There is also a timestamp record type, would this be picked up by date or should it be also added in?

[awelless]

Box supports dates only. I.e. the time part is 00:00:00.000. I find that treating timestamps as a date is quite risky, as we'll have to drop the time.

If someone wants to put timestamp as a date, they should do the conversion themselves.