Support distinguishing flavours

[mtesseract]

This work is part of a proof-of-concept for https://issues.redhat.com/browse/ROX-8711.

The basic idea here is that we would like to execute the Helm chart's test suite also in the case where we pre-render the chart files in "deployment bundle mode".

However, the difficulty is that in general the tests require some modification depending on whether executed in the "Helm chart mode" or in the "deployment bundle mode".

This PR extends the helmtest framework such that tests can be run selectively, depending on a "flavour" value, which is passed in by the user of helmtest and which can be accessed by the leave tests defined in the test suite.

[misberner]

To be honest, I'm not a fan of this approach. It seems very limited/tailored towards a single use case, when a more general approach that doesn't rely on introducing a concept foreign to Helm charts would work as well.

Here's a rough idea sketch, off the top of my head:

• Instead of flavor, we could use either the Helm release name (.Release.Name) or the .Release.Service value. We currently don't rely on either to distinguish kubectl vs true helm, because they aren't available at the meta-templating level. However, it seems reasonable and in line with Helm's design to either set a different release name or service (or both) when rendering kubectl templates (edit: I found that actually the chart name is different at least for sensor, so that could also be used)
• Instead of suppressing individual test cases, allow conditional expect statements. Thus, in addition to supporting a multiline string for expect, allow a list of the following form (the individual YAML labels can obviously be different):

expect:
- that: <some kubectl bundle-only property>
when: .helm.Chart.Name == "sensor"

WDYT?

[mtesseract]

Sounds like a good solution, thanks for the feedback.

[mtesseract]

@misberner , just want to make sure that we are not looking at this feature for helmtest in isolation, since this is directly connected to the work in stackrox/stackrox#218.

Do you plan to do a separate review of the PoC of the stackrox PR? We should be aligned on what changes we actually aim for before we iterate on this helmtest feature, I think.