feat(diagnostics): Add frontend for Heap dump analysis

[Josh-Matsuoka]

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 all commits using a GPG signature

To recreate commits with GPG signature git fetch upstream && git rebase --force --gpg-sign upstream/main

---

Fixes: #

Description of the change:

Adds a frontend for visualization of heap dump data.

How to manually test:

1. Pull and build with all related PRs
2. Trigger a heap dump in an agent target
3. Navigate to Analyze Heap Dumps, check the visualizations

[andrewazores]

1. "Diagnostics > Analyze > Heap Dumps" should probably be renamed "Diagnostics > Analyze > Heap Dump Archives" to be symmetric with Thread Dump Archives. The page titles should also match - currently on the "Thread Dumps Archives" view, the title above the tabs just says "Thread Dumps".
2. The navigation layout being "thread dump archives, analyze thread dumps, analyze heap dumps, heap dump archives" seems odd. Maybe "thread dump archives, analyze thread dumps, heap dump archives, analyze heap dumps"?
3. The heap dump archives table is missing the action menu item to jump to the analysis view

[andrewazores]

The right side legends of these charts seem to be cut off with no way to view the full label text, so it's not very meaningful as it stands. Maybe the charts should be left-justified within their container cards so that there's more space to the right for the labels, and the container cards could also be full page width.

For the quarkus-cryostat-agent sample application, which is a very small test case, this view is incredibly long and would probably benefit from some pagination - even if it's just client-side. Having all of the content in browser memory is probably not terrible, but making the browser render all of that content and having such a long scrollable viewport is not ideal and makes it rather sluggish to respond to click events.

Same here regarding length/scrolling/pagination. Also, I like how the Problem Fields tab has sortable columns. I think the Histogram should, too. The columns names here are also truncated and there seems to be no way to see what the full column name actually is. If these columns are in bytes, which I think they are, it might also be good to use the formatBytes utility to make it a little more readable.

Same thing here regarding pagination and sortable columns and maybe formatBytes (unclear currently, I can't tell what the displayed values are).

High Size Objects is pretty good, same as Problem Fields, in that it's sortable and the column names are hoverable to see the full name, but it probably could use pagination and formatBytes still.

Weak Hashmaps don't show up in this simple test so the same comments above may apply here as well.

[andrewazores]

Maybe along with pagination some text filtering would also be nice. The Event Types table is a good template to follow for what I'm hoping to see.

[andrewazores]

Can we have some descriptive text or some tooltips to explain certain things? Maybe users who are familiar with investigating heap dumps on a regular basis or who've used JMC (or maybe other similar tools) to analyze heap dumps before will understand what all of this means, but I don't think looking at this view it's really obvious what problem we're reporting to the user:

What is the problem with these fields, or why are they problems? What is the overhead of a problem field? Is there a reason to even render results for classes with the NO_FIELDS result type?