MINIFICPP-2679 Move HTTP tests to modular docker tests

[lordgamez]

https://issues.apache.org/jira/browse/MINIFICPP-2679

Depends on github.com//pull/2075

---

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.

[szaszm]

This way of deciding what to do raises a red flag for me, but I'll leave it up to @martinzink to say if this design fits in the framework or not.

[lordgamez]

In the first design of the new framework the flow building steps assumed that the steps are only meant for minifi and that there is only 1 minifi container in the test scenario. Later this was changed to be able to have multiple minifi containers in a test scenario and for that containers are identified and stored by their names. As we only have a single NiFi container in all of our tests involving NiFi it seemed to be the easiest approach to check the container name in case we want to add a flow step to the container. I also see that this may be a bit iffy in case we want to use multiple NiFi containers in a scenario in the future, but I could not find a better yet clean solution for this, so it can be up for discussion and I'm open for new ideas.

[martinzink]

what if we were to instead modify the steps so its explicit that its the nifi flow so we dont have to do this if minifi_container_name == "nifi"

e.g.
And a ListenHTTP processor with the "Listening Port" property set to "8081" in NiFi

instead of the current
And a ListenHTTP processor with the "Listening Port" property set to "8081" in the "nifi" flow

[lordgamez]

It could work if we rename the get_or_create_minifi_container to get_or_create_flow_container for example. In that case we expect that "nifi" container to already exist in the container map before adding a new processor, so it returns a NifiContainer instead of a MiNifiContainer in that case (we could create a common base class at least for a common return value). If the container does not exist yet we would always return a MiNifiContainer. It still feels a bit strange to just always expect NiFi container to be created beforehand and have the default return value to be a MiNifiContainer object, but I can live with it. What do you think?

[martinzink]

I rather not do that and separate this whole NiFi thing from the framework and handle this Nifi container as we would with any other thirdparty container with fully separate steps and implementations and not meddle with the current minifi ones, or is there something that prevents/complicates that approach?

[lordgamez]

My thinking was that in that case we would have to reimplement the same flow building behave steps for NiFi which would result in a lot of duplication, but if there is just minimal number of steps that are needed, like for processor creation and attribute setting, I think it can be contained with some minimal refactoring. I'll check and implement it that way if it seems viable.

[martinzink]

thanks, that would be awesome