NIFI-6310 Add OctetCounting parsing to ListenTCP

[juleslagarde]

Summary

NIFI-6310 Add OctetCounting parsing to ListenTCP. This then allows to use ParseSyslog Processor/Reader to parse syslog.

I added a ParsingStrategy in the parameters of ListenTCP. The default hasn't changed it still SPLIT_BY_DELIMITER. I added 3 other ParsingStrategy :

• DISABLED : no parsing, split messages only when the connection closes
• OCTET_COUNTING_STRICT : parse incomming data following strictly OctetCounting format.
• OCTET_COUNTING_TOLERANT : prefer OctetCounting but switch to SPLIT_BY_DELIMITER if the OctetCounting frame is invalid.

Since the defaults haven't changed should be retro compatible.

octet counting ref: RFC 6587 section 3.4.1

Tracking

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

Issue Tracking

• [x] Apache NiFi Jira issue created

Pull Request Tracking

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

Pull Request Formatting

• [x] Pull Request based on current revision of the main branch
• [x] 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

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

Licensing

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

Documentation

• [x] Documentation formatting appears as expected in rendered files

[juleslagarde]

1. Maybe I should rename ParsingStrategy to BatchingStrategy ? (too align with Batching Message Delimiter)
2. rename "Delimiter Replacement String" to "Batching Message Delimiter Replacement" (to align to "Batching Message Delimiter")

[github-actions[bot]]

Automated review is marking this PR as stale due to lack of updates in the past four months. This PR will be closed in 15 days if the stale label is not removed. This stale label and automated closure does not indicate a judgement of the PR, just lack of reviewer bandwidth and helps us keep the PR queue more manageable. If you would like this PR re-opened you can do so and a committer can remove the stale label. Or you can open a new PR. Try to help review other PRs to increase PR review bandwidth which in turn helps yours.