feat(graphql): implement k8s-style label selectors

[andrewazores]

Closes #846
Closes #825
Closes #822
Closes #821
Closes #820

This adds labels to GraphQL query filters for nodes in the deployment tree and for recordings, as well as annotations to query filters on target nodes. For annotations the Cryostat-generated annotations and the platform-provided annotations are merged together into one map. Both the labels and annotations query fields are optional, and can be given a Kubernetes label selector expression to match against the labels or annotations maps on the objects being queried.

[jan-law]

The label equality matchers are working well with both labels and annotation filters. Just had a question about the set matchers

[andrewazores]

With the latest commit you can perform a query like:

query {
    environmentNodes(filter: { name: "JDP" }) {
        name
        nodeType
        descendantTargets (filter: { annotations: ["PORT in (9091, 9096)", "env != production"] }) {
            target {
                alias
                annotations {
                cryostat
                }
            }
        }
    }
}

GraphQL also seems to support a sort of "bare singleton" for lists, so you can also do:

query {
    environmentNodes(filter: { name: "JDP" }) {
        name
        nodeType
        descendantTargets (filter: { annotations: "PORT in (9091, 9096)" } ) {
            target {
                alias
                annotations {
                cryostat
                }
            }
        }
    }
}

[jan-law]

Looks good!

Looking ahead, will there be other documentation (eg on HTTP_API or cryostat.io) for these 2.1 GraphQL features besides the blog posts?

[andrewazores]

I think a general description of the GraphQL endpoint in HTTP_API.md makes sense, but since that endpoint has so many possibilities in operation depending on the query sent, it's a little too hefty to describe it all there. There is still the GRAPHQL.md and the graphql/ examples hanging around which I had intended as temporary and to be cleaned up later, but perhaps it makes sense to clean them up and keep them around as in-repo docs. There should also be some form of documentation for this feature that also makes it onto cryostat.io for upstream docs, as well as something similar to whatever that ends up being for downstream product docs.

[jan-law]

Whoops, just saw this now