Add grype db providers command

[ADorigi]

Issue

resolves #2131

Changes

• Provider data is read from provider-metadata.json file.
• Added flag -o/--output flags which accept json and table.
• Display logic is separate from the provider data collection.
• Can be easily updated for db schema v6.
• Fails gracefully, with relevant error message, for absence of provider-metadata.json file.
• Updated Readme.md for the new command.

[willmurphyscode]

Hi @ADorigi thanks for the quick work here!

We need a couple things before we can merge it.

1. Can you clean up static analysis so that it passes? I think running make lint-fix and committing the resulting diff is all that's needed. You can check locally whether make static-analysis passes - that's the same check as runs in CI.
2. Can you add a test for this command? You could either add a unit test as a sibling of your new file, or a CLI test in https://github.com/anchore/grype/tree/main/test/cli that proves the new command exists and prints the right sort of thing.

Let me know if you have any questions! Thanks!

[ADorigi]

@willmurphyscode
I have addressed the following:

1. Cleaned the branch with make lint-fix and make static-analysis, ensuring it passes.
2. Added a test for the grype db providers command in the test/cli directory.

[willmurphyscode]

Hi @ADorigi! Thanks for getting up a rev that passes the validations. I have being trying out the command locally, and I have some additional feedback. There are some things that need to change in order to merge this, and some things that are merely nice to have, listed separately here:

Things that need to change

• grype db providers defaults to raw output, which is surprising; all our other commands without --output / -o default to a table output, so we need this to also default to table output.
• grybe db providers uses cell delimiting in the table output, which puts in extra lines and delimiters like | show up in grepped output. Please copy the table writers settings from https://github.com/anchore/syft/blob/326754509791f55d051bb9808009de1e2fc0add5/syft/format/table/encoder.go#L71-L82 - it should look like the table from grype or syft's default command.
• Remove -o raw: We're going to change the internal representation of this data very soon, so providing access to the raw data is setting people up to count on we know will change. Let's remove -o raw and just have table and JSON output.
• testing: the CLI test for the JSON output doesn't assert that the output is actually JSON. Copying the trait assertion from https://github.com/anchore/syft/blob/326754509791f55d051bb9808009de1e2fc0add5/test/cli/trait_assertions_test.go#L33 and invoking in in the -o json test would make these tests a lot more valuable.

Nice to have changes:

• nitpick: internal.TableOutput etc. constants are too broadly scoped - I realize that you did this to make the linter stop complaining about duplicate string literals, but db diff and db providers are totally different, so they should really each have their own constants.
• For extra credit: create some exemplary unit tests in cmd/grype/cli/commands/db_providers.go. I realize there aren't great examples to work from, but if you could get a small table test going that checks on different outputs, you could move cases besides -o json into unit tests and keep the CLI tests small.

[ADorigi]

Hello @willmurphyscode
Thank you for explaining the required changes in detail. Greatly appreciate the same.

I have made the following changes:

• Updated the default output format to be table, to align it with the other commands.
• Updated the formatting of the tablewriter to match the one in syft.
• The db providers command supports only table and json as the output formats, with table now as default.
• Added json and table trait assertions for the cli tests.
• Limited the use of constants to only the db providers command
• Updated test files
  • added a test file alongside cmd/grype/cli/commands/db_providers.go, to test individual components of the implementation
  • tests in test/cli/db_providers_test.go deal with how the command will actually be used.
  • as mentioned, I have not used any concrete example for these tests and will be willing to update them if required.