advisory: move command

[Dentrax]

Move a package's advisories into a new package.

This command will move most advisories for the given package into a new package. And rename the
package to the new package name. (i.e., from foo.advisories.yaml to foo-X.Y.advisories.yaml) If the
target file already exists, the command will try to merge the advisories. To ensure the advisories
are up-to-date, the command will start a scan for the new package.

This command is also useful to start version streaming for an existing package that has not been
version streamed before. Especially that requires manual intervention to move the advisories.

The command will move the latest event for each advisory, and will update the timestamp
of the event to now. The command will not copy events of type "detection", "fixed",
"analysis_not_planned", or "fix_not_planned".

---

Test it:

1. `go install .`
2. Jump to https://github.com/wolfi-dev/advisories/ dir
3. Run `wolfictl advisory stream kyverno kyverno-1.12`

[luhring]

Thanks for doing this, @Dentrax! This looks like it will be useful.

One overall question before diving in too deep: would this be more useful as a generalized "move"/"rename" command? It sounds like one use case is when we start to version stream a package that wasn't version streamed before, like the kyverno example. But IIUC, the same logic applies for any package rename — does that sound right to you?

I'm wondering if by generalizing this command to something like wolfictl advisory mv (inspired by and analogous to the Unix mv command, which handles file renames too), and keeping almost all of the logic in this PR (minus the version stream regex checking), we'd solve not just the "new version stream" case but all package rename cases... and also be well on our way to a "moved across repos" solution as well. What are your thoughts? Feel free to tell me I'm misunderstanding things here. 😄

[Dentrax]

Great advice @luhring! Renamed to move (mv). 👍

[luhring]

Would you mind looking at the code a bit again before we review further? It looks like there is still some version stream logic left over, documentation files from the old command name, and references to scanning that we ended up deciding not to do. Once this is in a state that's ready for more scrutiny, just ping me!

[Dentrax]

Apologies for the oversight @luhring! I should have double-check it.

It's now ready for review. PTAL when possible!

and references to scanning that we ended up deciding not to do.

I couldn't find this, actually i didn't include this functionality. 🤔

[luhring]

nit: This feels a little awkward to me. Could we capture the event we want, then do the timestamp update, and then just return a slice that includes that event? (It seems strange to operate on the event within the slice when we don't need to)

[luhring]

It looks like this PR still needs some cleanup from our last discussion?

[luhring]

What is this line for? It looks like we're testing the removal in the test block below?

[luhring]

Should we also test that other configs weren't removed and are still available?