KOGITO-1959: BDD tests: add possibility to check for errors in the wa…

[Sgitario]

JIRA Ticket: https://issues.redhat.com/browse/KOGITO-1959
Description: Add a new errorCondition closure to the WaitFor utility in order to define when to stop waiting for a condition.

As golang does not support having the same method with different arguments, we provide default methods to add the error condition (at the moment, only two):

• NoErrorCondition: when we don't want any error condition
• CheckPodsByDeploymentConfigInError: check whether pods under one deployment config is in error state (at the moment, only checks whether is ErrImagePull - the image can't be found
• CheckPodsWithLabelConfigInError: same as above but using one label

Many thanks for submiting your Pull Request ❤️!

Please make sure that your PR meets the following requirements:

• You have read the contributors guide
• Pull Request title is properly formatted: [KOGITO-XYZ] Subject
• Pull Request contains link to the JIRA issue
• Pull Request contains description of the issue
• Pull Request does not include fixes for issues other than the main ticket
• Your feature/bug fix has a unit test that verifies it
• You've tested the new feature/bug fix in an actual OpenShift cluster

[Sgitario]

I've tested a few features and they ran ok, but still need to verify more features.

[Sgitario]

@sutaakar and @radtriste I've updated the PR according to your comments by adding a new method with the error condition closure. However, I would rather prefer having only one method as it was previously. Having only one method empathises that when using the waitFor is a good practice to provide also an error condition. With two methods, maybe we even won't notice about this possibility.

[sutaakar]

@Sgitario @radtriste I have an idea, what about using varargs for error conditions?
That way we can keep just one method and allow defining multiple error conditions.

[radtriste]

sounds good to me

[Sgitario]

@sutaakar good idea! I've already changed the method to use optional arguments, this way:

• we only have one method
• we can provide more than one error conditions if needed
  Thanks!

[Sgitario]

I ran a few scenarios and everything looks working fine.

[radtriste]

@MarianMacik can you please have a look ?

@Sgitario Can you rebase ?

[Sgitario]

Rebased and conflicts resolved.