feat(uploads): add maxFiles configuration policy to jvmId uploaded recordings

[maxcao13]

Welcome to Cryostat! 👋

Before contributing, make sure you have:

• Read the contributing guidelines
• Linked a relevant issue which this PR resolves
• Linked any other relevant issues, PR's, or documentation, if any
• Resolved all conflicts, if any
• Rebased your branch PR on top of the latest upstream main branch
• Attached at least one of the following labels to the PR: [chore, ci, docs, feat, fix, test]
• Signed the last commit: git commit --amend --signoff

---

Fixes: #1306

Description of the change:

This change allows any client which posts a recording to the target-specific upload handler RecordingsFromIdPostHandler to specify the maxFiles parameter which keeps a set amount of archived recording files per target, depending on the given parameter. If the parameter is not specified, then it is defaulted to the env variable CRYOSTAT_PUSH_MAX_FILES. If that env var is not specified, the global maxFiles value is Integer.MAX_INT.

Motivation for the change:

See #1306 for discussion.

How to manually test:

1. Run normally...
2. On a target e.g. (cryostat:9093), start a recording and archive it (turn off archiveOnStop to make it easier).
3. Find the target's jvmId.
4. Then ->

$ https --verify=no -f -v POST :8181/api/beta/recordings/${jvmId} recording@testfolder/jfr/quarkus-test-agent_default_20230109T001426Z.jfr maxFiles=1 --auth=user:pass 

Notice the extra new paramter maxFiles. If we set it to 1, it will delete all archived files within the target except the one that was included in this upload form. If set to anything above 1, it will keep the old archived recording, plus the recent uploaded one that is included in the form.

Experiment with settings, (e.g. without a maxFiles, this should default to the environment variable config that was either set, or defaulted to Integer.MAX_INT)

[mergify]

Pull Request blocked. web-client submodule updates are performed automatically by CI when that repository is updated. Please revert or drop all changes to the web-client submodule from this PR and perform any required frontend work by opening and merging a PR against cryostat-web.

[github-actions]

Test image available:

$ CRYOSTAT_IMAGE=ghcr.io/cryostatio/cryostat:pr-1333-4cb90b936aabdba6487f63bf2001ffcdb23df30f sh smoketest.sh

[maxcao13]

Thoughts before tests?

[github-actions]

Test image available:

$ CRYOSTAT_IMAGE=ghcr.io/cryostatio/cryostat:pr-1333-681e4425914aada56d3a839cd47d721340c4316e sh smoketest.sh

[tthvo]

Looks good to me!

I was just seeing some front-end bug that renders duplicated archives. Try uploading an archive while in archive table view and there will be duplicate recordings.

Below, a single uploaded notifications renders an additional of 3 rows.

Probably another hook deps issue that eslint misses. Should be similar the upload table issue but we might forget to fix this too.

EDIT: See cryostatio/cryostat-web#820

I think PR is looking great. This bug probably can be solved separately on front-end.

[github-actions]

Test image available:

$ CRYOSTAT_IMAGE=ghcr.io/cryostatio/cryostat:pr-1333-d6e1bd9a47a85aa46bf33e86a2dfe7952ead9316 sh smoketest.sh

stale

[tthvo]

Spotless?

[github-actions]

Test image available:

$ CRYOSTAT_IMAGE=ghcr.io/cryostatio/cryostat:pr-1333-af3185d17464f853b2b73adcf206d1562d909f49 sh smoketest.sh

[andrewazores]

Just needs a note added to the README describing the new variable.

[github-actions]

Test image available:

$ CRYOSTAT_IMAGE=ghcr.io/cryostatio/cryostat:pr-1333-e23fb62ebde3d109e5efc116b663ef56da6f90cb sh smoketest.sh

[tthvo]

Looks great to me :D Worked well.