Improve the wording around the InvalidNullByteException

[LakshSingla]

Description

This PR improves the wording around the mysterious InvalidNullByteException. The exception occurs when the strings that are added to the frame contain the 0x0000 byte which is internally being used as a delimiter in the case of a string column. The current use case for the frames is MSQ exclusively, and this error will only be generated if the ingested external data contains hidden null bytes, which in most cases can safely be sanitized.

This PR has:

• been self-reviewed.
  • using the concurrency checklist (Remove this item if the PR doesn't have any relation to concurrency.)
• added documentation for new or modified features or behaviors.
• a release note entry in the PR description.
• added Javadocs for most classes and all non-trivial methods. Linked related entities via Javadoc links.
• added or updated version, license, or notice information in licenses.yaml
• added comments explaining the "why" and the intent of the code wherever would not be obvious for an unfamiliar reader.
• added unit tests or modified existing tests to cover new code paths, ensuring the threshold for code coverage is met.
• added integration tests.
• been tested in a test Druid cluster.

[abhishekagarwal87]

thank you for making this error message more actionable.

[paul-rogers]

Thanks for the improved message. The user, however, knows nothing about frames. Can we word this from the user's perspective?

Druid does not support null (0x00) bytes in strings. File %s, row $d, column %s contains null bytes: [%s].

The string would be encoded so that control characters appear as \U0000 so the user can see the position of the null bytes.

Maybe we don't know the row number (in a form useful to the user.) If not, just list the column.

This is a case of unparsable data. Should we have caught it at the time we read the data rather than when writing to a frame? Should we invoke our bad-row logic to skip this row? That logic should log the bad row for later re-ingestion, but I don't think we've added that ability.

If we catch the problem on read, then the check here is more of an assertion. Though, perhaps the data was created by an expression, so it is still worth validating.

[github-actions]

This pull request has been marked as stale due to 60 days of inactivity.
It will be closed in 4 weeks if no further activity occurs. If you think
that's incorrect or this pull request should instead be reviewed, please simply
write any comment. Even if closed, you can still revive the PR at any time or
discuss it on the dev@druid.apache.org list.
Thank you for your contributions.

[LakshSingla]

Raised an improved PR tackling this issue