Change Bugzilla collector and Flaw model to allow multi-components in bz_summary

[costaconrado]

This PR changes the way Bugzilla collector parse summary.

This PR changes flaw model so component can support multiple components.
This PR also changes the parser of bugzilla collector to bz_summary be parsed as a list instead of a single component.
This PR introduces a major change in API (component became components) and the filter for flaws changed in order to support it.
This PR also adds a property called component_str for checks that uses component as a condition.

Closes OSIDB-1420.

[costaconrado]

To reviewer: Sorry for the single commit PR with multiple changes, the migration should be the 1st and it makes the API fail the tests making it unable to be in a different commit.

[Elkasitu]

This change is not backwards compatible and contains non-safe migrations, the easiest solution at this point in time would probably be:

• Keep component field as-is
• Deprecate component field in the API
• Create new field components, prefill with existing component field
• Expose components field in API

[osoukup]

The new functionality looks OK to me but I agree with @Elkasitu that we should for now keep the old component field for the backward compatibility. It should be deprecated and maybe just return the first item from components list.

[costaconrado]

Makes sense, I've deprecated the component field and added the components. @osoukup do you think it would be better to return the 1st value of components or split the value by colon and do a contains? (e.g. if user pass golang: archive/zip I return all flaws that contains both golang and archive/zip)

[osoukup]

Makes sense, I've deprecated the component field and added the components. @osoukup do you think it would be better to return the 1st value of components or split the value by colon and do a contains? (e.g. if user pass golang: archive/zip I return all flaws that contains both golang and archive/zip)

@costaconrado I am not sure I understand the question 👼 I mean that the value of the old attribute component should simply be the first item in the new components list attribute. It was just mean for the backwards compatibility so there is some meaningful value until we deprecate it full. It is probably not very important which item from components would be returned as the component - first/last/random/whatever. Just some meaningful value. It will be temporary anyway.

[osoukup]

I propose slight changes in how the old component is treated - it is rather a single component even though there are multiple of them in the original Bugzilla summary and I think it should be still consider so before we remove it.

[osoukup]

nitpick: separed to separated

[costaconrado]

I have changed the behavior so component returns the last value of components returning the same value it would return without this PR. Also if user pass something like golang: net/http to the old field it will be not parsed, just accepted as a single component.
I have also removed the field component from tests that uses apps.workflows.checks, the previous solution created a component_str property in flaw model but as discussed before it currently not is being used anywhere but in the test.

Please take a second look in this PR when you have some time @osoukup. Thanks!

[osoukup]

LGTM