feat(archives): add non-target-specific "all-archives" view

[maxcao13]

Fixes #546
Related https://github.com/cryostatio/cryostat/pull/1110
Depends on https://github.com/cryostatio/cryostat/pull/1110

Must be tested with the above back-end PR to work.

[maxcao13]

Thoughts before tests?

The new view works differently in that notifications refresh the entire page. This is done because the querying to the backend actually happens in the parent component AllArchivedRecordingsTable which contains multiple nested ArchivedRecordingsTables <- these normally update state by themselves but the new view has a entirely different set of api calls that don't depend on jvmIds and such so I would have to create a new ArchivedRecordingsTable-like component to properly handle notifications instead of just refreshing the page, which I haven't done. It is entirely possible to do, but I'm not sure if this the current state is okay enough since tomorrow is the deadline.

[andrewazores]

Sorry, I won't have time to review this fully tonight, but I will get it done tomorrow before making the upstream branches.

The full-view refresh on notification sounds fine for now, I don't expect this to be a popularly-used view in most scenarios, so it's OK if we leave a performance optimization on the table for later.

[tthvo]

Looks good overall to me. Just some questions :D

[tthvo]

Thoughts before tests?

The new view works differently in that notifications refresh the entire page. This is done because the querying to the backend actually happens in the parent component AllArchivedRecordingsTable which contains multiple nested ArchivedRecordingsTables <- these normally update state by themselves but the new view has a entirely different set of api calls that don't depend on jvmIds and such so I would have to create a new ArchivedRecordingsTable-like component to properly handle notifications instead of just refreshing the page, which I haven't done. It is entirely possible to do, but I'm not sure if this the current state is okay enough since tomorrow is the deadline.

One way to go around this issue (i.e. similar to AllTargetArchive) is that the parent AllArchive can query only the list of directories and counts. Then, pass in an optional DirectoryOptions props including the directory info to the ArchiveTable. Then, the archive can check if this option is available, and make the api calls to fetch recordings for that directory. I think we should do the same for uploads. But this seems to require some refactoring and maybe backend supports :D

[andrewazores]

@tthvo @maxcao13 please file an issue (or issues) to track these planned improvements to this view so we can put them on the backlog to be addressed after the release branchpoint.

[andrewazores]

Just had one suggestion for the way the rows are rendered on the new table. PR opened against this feature branch here:

maxcao13#1

[github-actions]

This PR/issue depends on:

• cryostatio/cryostat#1110
  By Dependent Issues (🤖). Happy coding!

[andrewazores]

@maxcao13 I updated your PR bodies for this and the backend PR to invert the depends-on relationship between them. Now that we have a CI hook to automatically update the submodule in the backend repo we can do it this more intuitive way.

[andrewazores]

@tthvo thanks for taking the code review earlier, I've given it a brief look-over after your more thorough review and things look OK. It works well, too. Other than my suggestion PR to change how the rows are displayed I have no further requests.

[andrewazores]

Oh, I didn't update the snapshot test along with that PR I made. Could you update that yourself @maxcao13 ? Good to go after that, I think.

[tthvo]

@tthvo @maxcao13 please file an issue (or issues) to track these planned improvements to this view so we can put them on the backlog to be addressed after the release branchpoint.

Right, I filed the issue for refactoring at #552 :D

[tthvo]

Looks great now! Thanks for making this features :D