MINIFICPP-1457 - Implement InputRequirements

[adam-markovics]

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

For all changes:

• Is there a JIRA ticket associated with this PR? Is it referenced
  in the commit message?

• Does your PR title start with MINIFICPP-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.

• Has your PR been rebased against the latest commit within the target branch (typically main)?

• Is your initial contribution a single, squashed commit?

For code changes:

• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
• If applicable, have you updated the LICENSE file?
• If applicable, have you updated the NOTICE file?

For documentation related changes:

• Have you ensured that format looks appropriate for the output in which it is rendered?

Note:

Please ensure that once the PR is submitted, you check GitHub Actions CI results for build issues and submit an update to your PR as soon as possible.

[arpadboda]

I think this should allow - the process to be executed can be speficied in flowfile attributes and whatnot

[adamdebreceni]

it can be specified but it seems to me, that it won't be used, this might be a bug

[adam-markovics]

Input is also forbidden in NiFi, I will ask them what they think about this.

[adam-markovics]

ExecuteStreamCommand is the one in NiFi that accepts commands from an incoming flowfile. We don't have that (yet?).

[arpadboda]

Yep, makes sense to differentiate the two, but that's definitely out of scope of this change.
Leave it as "allowed" for now, later we can align the processors to NiFi

[adam-markovics]

Done.

[lordgamez]

LGTM

[szaszm]

While the PR looks functional, and the functionality is very appreciated, I have issues with the design. See my comment below.

[szaszm]

This implicitly disables move, because it's a non-static const data member, inherited by the . It should be static constexpr IMO. It also pollutes the scope of derived classes with an overly generic name value_, because it's all used through inheritance.

I don't like using inheritance for this purpose. I would prefer if classes could just declare their requirements by creating a type alias of a well known name, like struct MyProcessor : Processor { using input_requirements = annotation::input::required; };. In other words, using type traits to check this at compile-time, with no runtime cost, less invasive dependencies and less pollution.

[adamdebreceni]

compile-time would be a nice touch, but I don't see how could we verify at compile-time that a processor requiring inputs actually gets some input connections, also wouldn't this require the code to a) either cast all processors to their most derived type b) reimplement the input requirement validation for all processor types?

[adamdebreceni]

agree with the member pollution concern, we could get rid of the value_ altogether by trying successive dynamic_casts to Required, Allowed and Forbidden

[szaszm]

Good point about the compile-time requirements, I didn't think about not having the static type being the most derived type. As a runtime-friendly alternative, we could avoid using inheritance by introducing a new virtual function, something along the lines of getInputRequirements() const, or passing the enum value to the Processor base constructor for storage.