Breaking syft | grype or merging syft code that breaks grype tests should warn team

[willmurphyscode]

What would you like to be added:

The release of a new version of syft should exercise syft | grype and, if grype fails, warn the team that syft is ahead of grype, in the sense that the latest version of syft produces output the latest version of grype can't parse. The warning (e.g. slack alert to the team) should remind the team to promptly release grype so that the period where syft is ahead is very short.

Why is this needed:

#1935 is an example where we had customer impact because a syft release went out that the team didn't realize was incompatible with latest grype, and so syft | grype for latest syft and grype was broken for a couple of days.

[wagoodman]

Though failing CI in a PR isn't an option, adding a comment on the PR when it will break grype could be a good option in addition to your suggestion (in the vein of shift-left).

[willmurphyscode]

We discussed this issue again at retro, and the solution we were leaning towards was:

1. New commits on main in syft should create (or update if existing) a PR to grype that bumps syft in grype to the new commit.
2. Releases of syft should query for this PR and assert that its tests are is passing.
3. There should be a good way to override the checks in step 2 if needed.
4. When we release syft, we can then immediately merge this PR and release grype.

This way, regressions can be caught by grype's test suite, which is probably the right place for that.