[Epic] Pluggable Discovery Services

[andrewazores]

For Cryostat 2.2.0, we want to enhance the flexibility of the target discovery mechanism. Currently this is encapsulated in the Platform Module, in particular the Platform Detection Strategy and the Platform Client. This allows Cryostat to have some flexibility in determining where it is running and how it should discover target applications. But there are pitfalls:

1. These strategies are built in to Cryostat, so the behaviours are effectively hardcoded. OpenShift users, for example, can only do discovery by querying Endpoints and looking for ports with number 9091 or name jfr-jmx. They cannot customize the behaviour to use k8s Annotations or Labels or any other custom logic for their deployment.
2. There is a divide between the older flat design of ServiceRef that represents a single target application, and the newer hierarchical design of EnvironmentNode/TargetNode used in the Discovery tree API.
3. There is no persistent storage of this data (other than custom targets definitions).
4. Where possible we do listen for platform notifications and emit WebSocket notifications to notify our clients of changes to discovered targets, but we don't use these for updating the Discovery tree API model. The Discovery tree API is always re-queried from the platform when requested by one of our clients.
5. We expose a few different APIs that clients can use to get information about what targets are known: /api/v1/targets, /api/v2.1/discovery, and a few different queries under /api/beta/graphql. We should at least deprecate /api/v1/targets and replace it with an API V2+-compliant endpoint. The response data format here should match /api/v2.1/discovery and the GraphQL query responses as closely as possible.
6. Clients can make requests for discovery nodes (targets and their parents) with specified properties. For example, "all targets with label mylabel=foo". This need is served by GraphQL already from a client perspective, but on the backend the implementation is quite inefficient, since it performs a full platform query to determine the overall graph structure (see point 4 again), and then applies the specified property filters to the results. The implementation that solves points 3 and 4 should also lend itself to re-implementing this point more efficiently.

• [x] https://github.com/cryostatio/cryostat/issues/937
• [x] https://github.com/cryostatio/cryostat/issues/938
• [x] https://github.com/cryostatio/cryostat/issues/939
• [x] https://github.com/cryostatio/cryostat/issues/940