feat(#5352): healthgroups endpoint

[ulischulte]

Closes #5352:

Added caching and a dedicated REST endpoint for health groups.

When SBA polls an application's /health endpoint, the response may include a groups field (e.g., ["liveness", "readiness"]). Previously this data was fetched on-the-fly from the client. Now:

• HealthGroupsCache — A ConcurrentHashMap-based cache stores health groups per instance, updated automatically during each health status poll.
• GET /instances/{id}/health-groups — A new REST endpoint serves the cached groups directly, avoiding repeated calls to client applications.
• HealthGroupsCacheCleanupTrigger — Listens for InstanceDeregisteredEvent and evicts stale cache entries to prevent memory leaks.
• UI integration — The health details view (details-health.vue) now calls the new server-side endpoint instead of fetching groups from the client's health response.

Key design decisions

• Cache is populated as a side effect of the existing StatusUpdater health polling (no extra HTTP calls)
• Thread-safe via ConcurrentHashMap + List.copyOf() for immutable snapshots
• Backward-compatible: the protected convertStatusInfo(ClientResponse) API in StatusUpdater is preserved for subclasses
• @ConditionalOnMissingBean on all new beans allows customization

[cdprete]

This seems a bit an overkill to me.

It would be enough to invoke the deletion in the StatusUpdater with a doOnNext as it's already done to persist the groups (actually, it's enough to add an if there to check the event type and either call the save or the delete method).
We're scheduling a thread to constantly check for a single even type, which barely happens, where the StatusUpdater is already handling all of them anyway.

[ulischulte]

StatusUpdater polls the /health endpoint — it does not receive InstanceDeregisteredEvent. A deregistered instance simply stops being polled (doUpdateStatus returns early if !instance.isRegistered()), so eviction would never fire there.

I'll investigate a little further and probably will either
(a) keep a lightweight event subscription but reuse an existing handler/scheduler, or
(b) accept the small overhead since cleanup-on-deregister is the established pattern in SBA

[cdprete]

StatusUpdater polls the /health endpoint — it does not receive InstanceDeregisteredEvent.

Indeed. For a moment I had the impression it's handled there because the journal view shows all of them.

I'll investigate a little further and probably will either
(a) keep a lightweight event subscription but reuse an existing handler/scheduler, or
(b) accept the small overhead since cleanup-on-deregister is the established pattern in SBA

Wouldn't be enough to have a Spring Boot's @EventListener for the specific application event and remove the entry from the cache when it's received?

[cdprete]

Actually I think we should call the fetchHealthGroups when an SSE is received now, otherwise stale data may be potentially used.

This comment is not specifically related to this test case, but it's a more general statement.

[ulischulte]

Good catch, and agreed in principle. The current else branch only invalidates the per-group details (group.data = null) but keeps the previously fetched group list, so a group added/removed at runtime would indeed show stale entries until the instance id changes or the view is remounted (although this seems to be an edge case).

I'll update onInstanceChanged so the same-instance branch also calls fetchHealthGroups() (which already resets healthGroupOpenStatus/healthGroupLoadingMap and clears stale data), making the displayed group list self-correcting on SSE updates.

[cdprete]

Yep.
Also because, from @SteKoe in a previous PR about a Thymeleaf fix, I discovered that the configuration properties can be changed at runtime from SBA.

Probably, to cover this case as well, we would need SSE also for the health groups, but I don't know how much worthy it really is. Unless a STATUS_CHANGED even is also created when the health response body changes in general and not just by the status (UP, DOWN and so on).
Performance and code clearity wise, it would then indeed be better to update the model of the instance to also have the health groups in it.

[cdprete]

Ok, I double-checked the code in StatusUpdater and, if I'm not mistaken, it's pretty dumb in the sense that it does no check with the previous state but just pushes the new event.
As such, indeed re-fetching the groups on every instance change should be enough even to cover runtime config updates done over the SBA UI.

[cdprete]

I think we should ensure that groups are unique, either here by using a LinkedHashSet instead of a List or in the UI to avoid potentially duplicated entries.