cve_lib: priority reason change is brittle

TL;DR: I am not convinced cve_lib:cve_load() should through an error when a non-medium priority CVE does not have an associated explanation.

the recent change to add expand the priority field to include a description, and to require it for CVEs where the priority is given as anything but a medium (except for neglibile for some reason) after a certain CVE publication date, is brittle, because this is enforced at cve load time, and an exception is raised if the explanatory text is missing. Thus if we have a CVE that is in this condition, tools like scripts/ubuntu-table will fail, and unfortunately tools like scripts/pkg_status use ubuntu-table in pipelines that, while it will return an error code on exit, otherwise silently aborts.

This is a little bit problematic from a workflow perspective, the following being an example:
I am triaging CVE-2023-30577 in amanda, which is a borderline high; it's a local privilege escalation but to exploit it, one must be in the backup group, which is not a default group for users. I set the priority to high and check-syntax properly complained that the explanation for the priority is missing. so I wanted to see what other CVEs were open for amanda, because perhaps this should be the trigger to address all open vulnerablities in that package, especially since this is a fix on top of an earlier incomplete fix for CVE-2016-10729. However, using pkg_status silently returned nothing (beyond error code 1), and I had to take other means besides pkg_status to find CVE-2016-10729.

The workflow issue here is that once you have a non-medium priority issue without the reason, any tool that uses cve_lib's cve_load then breaks, preventing you from using them to identify other CVEs that affect the same package. Yes, one could work aorund by using grep or putting in a bogus description, but what it really does is incentivize people to keep assigning medium for everything.

Additionally, this can be triggered through a refresh of data from mitre and nvd, which we do on a weekly basis; sometimes the publication date of CVEs from them is adjusted, occasionally significantly forward in time, and our refresh process will pull those in -- we do this because the majority of the time they are reasonably accurate, but as with any large data set there are going to be errors.

Converting pkg_status to not be a bodged together shell script and converting it to python would only help in surfacing the breakage a little more prominently, it still would not report information until one made the priority medium or put in a placeholder description.