Implement user-specified target definitions

[andrewazores]

Initial backend support for #468.

Perhaps there should also be some metadata added to ServiceRefs to mark their source, ex. platform detection vs manually added, but that is currently not implemented.

Here we have two new V2 API handlers, for POST /api/v2/targets and DELETE /api/v2/targets/:targetId.

The POST request checks if there are any existing targets with an identical service URL and fails if so. If not, then a new ServiceRef is created using the service URL and alias provided (by POST form attributes) and tracked by the new CustomTargetPlatformClient.

The DELETE request simply removes any ServiceRef from the CustomTargetPlatformClient which matches the specified targetId path parameter.

The CustomTargetPlatformClient simply maintains an internal sorted set of ServiceRefs with add/remove methods to mutate this state. It also persists the state to disk on each write operation, and loads this state from disk when start()ed. This allows the user's custom target definitions to survive service restarts (assuming the configuration directory is mounted somewhere that will survive a restart - this is not the case by default in run.sh/smoketest.sh).

Results from the CustomTargetPlatformClient are combined with the pre-existing platform-specific client by the new MergingPlatformClient, which is pretty self-explanatory.

Frontend support for this feature will come later.

To test, use websocat and curl or httpie. The following steps use httpie.

Start container.
CRYOSTAT_IMAGE=quay.io/andrewazores/cryostat:custom-targets

Connect to notification channel.
$ websocat -kE wss://0.0.0.0:8181/api/v1/command

Create a new custom target definition.
$ http --verify=false -f POST https://0.0.0.0:8181/api/v2/targets connectUrl="service:jmx:rmi:///jndi/rmi://cryostat:9099/jmxrmi" alias="Fake"

Observe that this target is FOUND in the notification channel stream.
Check that it is reflected in the API results - it should be listed first.
$ http --verify=false https://0.0.0.0:8181/api/v1/targets

Delete the custom target definition.
$ http --verify=false DELETE https://0.0.0.0:8181/api/v2/targets/service%3Ajmx%3Armi%3A%2F%2F%2Fjndi%2Frmi%3A%2F%2Fcryostat%3A9099%2Fjmxrmi

Again observe that the target is LOST in the notification channel stream.
Check that it is no longer reflected in the API result.
$ http --verify=false https://0.0.0.0:8181/api/v1/targets

The web-client UI already has support for the notification events emitted since they reuse the existing platform discovery notification category and type information, so the POST/DELETE effects can also be seen in the graphical target list.

[andrewazores]

@Alexjsenn @Josh-Matsuoka any takers for a review?

[Alexjsenn]

I can do it!

[Alexjsenn]

Looks good!