[Task] Query responses for Recordings can exclude present Labels

[andrewazores]

Related to https://github.com/cryostatio/cryostat-web/issues/442

Here's one set of possible reproduction steps:

$ https :8181/api/beta/graphql?query="query{ targetNodes(filter: { annotations: \"PORT == 9091\" }) { doStartRecording(recording: { name: \"test\", duration: 30, template: \"Profiling\", templateType: \"TARGET\" }) { name state duration metadata { labels } } } }"
HTTP/1.1 200 OK
content-encoding: gzip
content-length: 129
content-type: application/json

{
    "data": {
        "targetNodes": [
            {
                "doStartRecording": {
                    "duration": 30000,
                    "metadata": {
                        "labels": {}
                    },
                    "name": "test",
                    "state": "RUNNING"
                }
            }
        ]
    }
}


$ https :8181/api/v1/targets/localhost:0/recordings
HTTP/1.1 200 OK
content-encoding: gzip
content-length: 254
content-type: application/json

[
    {
        "continuous": false,
        "downloadUrl": "https://localhost:8181/api/v1/targets/service:jmx:rmi:%2F%2F%2Fjndi%2Frmi:%2F%2Flocalhost:0%2Fjmxrmi/recordings/test",
        "duration": 30000,
        "id": 1,
        "maxAge": 0,
        "maxSize": 0,
        "metadata": {
            "labels": {}
        },
        "name": "test",
        "reportUrl": "https://localhost:8181/api/v1/targets/service:jmx:rmi:%2F%2F%2Fjndi%2Frmi:%2F%2Flocalhost:0%2Fjmxrmi/reports/test",
        "startTime": 1653689622808,
        "state": "STOPPED",
        "toDisk": true
    }
]


$ https :8181/api/v1/targets/$(echo -n service:jmx:rmi:///jndi/rmi://cryostat:9091/jmxrmi | jq -sRr @uri)/recordings
HTTP/1.1 200 OK
content-encoding: gzip
content-length: 288
content-type: application/json

[
    {
        "continuous": false,
        "downloadUrl": "https://localhost:8181/api/v1/targets/service:jmx:rmi:%2F%2F%2Fjndi%2Frmi:%2F%2Fcryostat:9091%2Fjmxrmi/recordings/test",
        "duration": 30000,
        "id": 1,
        "maxAge": 0,
        "maxSize": 0,
        "metadata": {
            "labels": {
                "template.name": "Profiling",
                "template.type": "TARGET"
            }
        },
        "name": "test",
        "reportUrl": "https://localhost:8181/api/v1/targets/service:jmx:rmi:%2F%2F%2Fjndi%2Frmi:%2F%2Fcryostat:9091%2Fjmxrmi/reports/test",
        "startTime": 1653689622808,
        "state": "STOPPED",
        "toDisk": true
    }
]

$ https :8181/api/beta/graphql query="query { targetNodes(filter: { annotations: \"PORT == 9091\" }) { recordings { active { name metadata { labels } } } } }"
HTTP/1.1 200 OK
content-encoding: gzip
content-length: 137
content-type: application/json

{
    "data": {
        "targetNodes": [
            {
                "recordings": {
                    "active": [
                        {
                            "metadata": {
                                "labels": {
                                    "template.name": "Profiling",
                                    "template.type": "TARGET"
                                }
                            },
                            "name": "test"
                        }
                    ]
                }
            }
        ]
    }
}

The first command uses the GraphQL API to query for a specific target node, then performs the doStartRecording mutation upon that node. The response is expected to include the labels present on the newly-started recording result, but the map is seen to be empty. Querying for information about recordings by using an "aliased" service URL (points to the same JVM, but isn't an identical URL) also results in the observed labels being empty. Repeating that query using the proper discovery service URL reveals the labels as expected. Finally, performing another similar query with GraphQL does actually show the labels being present.

I think this is actually two separate bugs, but need further investigation.

1. is related to https://github.com/cryostatio/cryostat-web/issues/442 . If we're querying for targets and have an "aliased URL" scenario, then we may miss the stored labels because we don't actually know that the JVM we're connecting to is the same one that we have stored labels for, for this recording. To solve this we need some way to uniquely identify actual JVM instances, not just track the URLs we use to connect to them. A single JVM might be reachable by any number of DNS hostnames for example, which all resolve to the same IP.
2. The GraphQL doStartRecording mutation response is probably returning the information about the recording before we have actually added the labels to it and persisted them. I think this is separate from the first bug because here it should be using the platform discovery provided URL for the target JVM and checking storage for that same expected URL in this case.