NIFI-11177: Add defensive code for null values for Iceberg

[mattyb149]

Summary

NIFI-11177 This PR adds defensive checks to return null values when any conversions occur

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

[mark-bathori]

Thanks @mattyb149 for fixing this null handling issue. Since every converter needs a null check in the convert(Object data) method I think it would be a better solution to add this null check in a new method in the DataConverter<S, T> abstract class and then this would call to the convert method. With this change we don't need to add the same null check to every implementation.

[mattyb149]

This should work since the top-level convert() is for each RecordField in the Record, but shouldn't we have the null checks in the individual convert()s too just in case convert() is called directly from somewhere else? Or do we trust in having the Record/Map/Array converters call the new method (I'm calling it convertWithNullCheck())?

[mark-bathori]

It shouldn't be called from other places but of course it could happen. I'm fine with the current solution also.
LGTM +1

[mattyb149]

I'll push a commit with the new method and change the complex types to call that, just for safety :)

[mark-bathori]

I think the last commit is not needed since the original solution contains null check in every convert implementation. The only issue could be if a new implementation would be added without a null check but it is very unlikely.