feat(rules): implement "archive" rules

[andrewazores]

Closes #645

Fixes #643

This implements an alternative and simplified version of the "one-shot" rules.

If a Rule definition is given where "eventSpecifier":"archive", the rule definition will not be persisted, does not require a unique name, may not have archivalPeriodSeconds/preservedArchives/maxAge/maxSize, and rather than starting a new recording will cause a snapshot to be taken, copied to archives, and the snapshot immediately removed.

The motivation is to allow a user to have a workflow such as the following:

POST /api/v2/rules

{
    "name": "monitor",
    "description": "Monitor application, all the time",
    "eventSpecifier": "template=Continuous",
    "matchExpression": "target.labels.app=='MyApp'",
    "archivalPeriodSeconds": 3600,
    "maxAgeSeconds": 300,
    "preservedArchives": 6
}

Wait some time and observe application metrics (JFR or otherwise), either manually or by an external automated process. When some trigger event occurs, such as resource utilization exceeding a threshold for longer than some duration, the user wants to get copies of their application's JFR data at that moment and for the previous lookback window (5min in this case due to maxAgeSeconds).

Note that this rule configuration gives the user a 5min window of data in the recording at any time, and that that 5 minute sample will be copied to archives only once per hour (3600 seconds). 6 such copies will be retained in the archives at any given time. Such a configuration could be used to gather ongoing continuous monitoring data, leaving long gaps in between archival periods to prevent excessive use of disk space, for example.

Alternatively, the rule definition may only start a continuous recording in the targets, without any configuration for periodic archiving.

POST /api/v2/rules

{
    "eventSpecifier": "archive",
    "matchExpression": "target.labels.app=='MyApp'"
}

After POSTing this second rule definition, Cryostat will connect to all of the same original set of targets and perform the snapshot/archive/remove snapshot procedure as explained earlier. The original recordings created by the first rule are still in place and running, so the user may re-POST the second rule definition as many times as they wish in the future as more external trigger events occur.

[jan-law]

Looks good otherwise

[hareetd]

Looks good