New rule definitions trigger on existing targets

[andrewazores]

With this change, adding a new rule definition causes that rule to become immediately activated for any matching targets that are already known. Prior to this change adding a new rule definition would only affect targets that (re)appear after the rule was added.

Example:

1. Run smoketest.sh

$ http --verify=false -f https://0.0.0.0:8181/api/v2/rules name=foorule description="Rule for testing" targetAlias=es.andrewazor.demo.Main eventSpecifier="template=Continuous"
HTTP/1.1 201 Created
content-encoding: gzip
content-length: 94
location: /api/v2/rules/foorule

{"meta":{"type":"text/plain","status":"Created"},"data":{"result":"foorule"}}

3. Check that the vertx sample app listening on 9093 has a new recording named auto_foorule. The other vertx apps on 9094 and 9095 require credentials, so they will not have matching recordings, but Cryostat's logs should reveal that it attempted to start recordings on them and failed due to the lack of credentials.

[jan-law]

Checking my understanding: Is the purpose of the RecordingCreationHelper to create a new recording, aka apply a new rule, to matching targets without going through the web client?

[andrewazores]

Pretty much, yes. The API handler for creating recordings used to process the POST request and form and then also handle all of the actual logic of creating the recording. It made sense to extract that out to somewhere reusable so that automatic rules can perform the same logic, but without having to do an HTTP request to ourselves and deal with a nested request/response (client -> cryostat -> cryostat -> client).

[andrewazores]

Rebased, the only conflict was just imports in the MainModule.

[jan-law]

Looks good! Will wait until @hareetd has had a chance to review this thoroughly

[hareetd]

Looks good!