KCIDB: v5.2 - issue categories + 🗳 POLL

[Nikolai Kondrashov <spbnick@gmail.com>]

Hello, everyone involved with sending results to KCIDB,

Please consider helping protocol development by filling this 5-minute form:

    🗳️ https://forms.gle/FsZL84bcAzqve1aC8

We now have full support for ingesting v5.1 schema, including the new
"origin_builds_finish_time" and "origin_tests_finish_time" checkout fields.

So, we could move onto the next change in v5.2, adding support for
categorizing reported issues:


https://github.com/kernelci/kcidb-io/pull/98/commits/e7ba6a9f351a724f69a556f7967f96bb83e398e4

We already have the ability to determine if a reported issue is a build or
a test issue, and if it's e.g. a boot issue. However, it requires joining with
its incidents and the incident builds and tests. That is costly, and still
doesn't let you have finer categorization, such as "which kind of build or
boot issue is that"?

So, we'd like to add a field to issues specifying the categories it belongs
to. The categories themselves would be standardized outside the schema, and
discussed separately.

The new "categories" issue field would accept an array of "path" strings, exactly
like the ones we use for tests, but this time pointing to nodes in issue
categorization tree. E.g.: "build.error", "build.warning", "boot.oops", etc.

Here's a sample for an illustration:

{
    "version": {
        "major": 5,
        "minor": 2
    },
    "issues": [
        {
            "id": "maestro:ab266247c76746e5ccdc49ba08c7d1f10996cd12",
            "version": 2,
            "origin": "maestro",
            "culprit": {
                "code": true,
                "tool": false,
                "harness": false
            },
            "comment": "too many arguments to function call,...",
            "categories": [
                "build.error",
                "compiler.error",
            ]
        }
    ]
}

As the change is minor and backwards-compatible, I'd like to set the feedback
deadline to the end of the week, Fri, Mar 28. If there are no objections by
that time, I'll merge this change to the schema and database support on that
day.

Nick