feat(supervisor): add resource status severity

[andreafalzetti]

Description

• Extends status.proto with ResourceStatus severity to remove the duplicated severity calculation from each client
• Refactor gp-cli and jetbrains backend-plugin to consume the new severity property

Related Issue(s)

Fixes #12075

How to test

1. Launch a workspace https://afalz-1207846d967e0b.preview.gitpod-dev.com/#https://github.com/gitpod-io/gitpod
2. Select IntelliJ latest as preferred IDE
3. Stress the CPU/Memory and using both gp top and JB backend control center, see the cpu/memory thresholds change color to WARN/DANGER

Release Notes

NONE

Documentation

Werft options:

• /werft with-preview

[jeanp413]

To be honest I don't see the benefit of this change, APIs should provide the basic info/data and users of the API can use/interpret it freely. Even though it seems repetitive to map from values and threshold it's fine and the code is really simple.
I also see you are doing a mapping either way in GitpodMetricProvider.kt it's the same in the end. 🤔

[andreafalzetti]

To be honest I don't see the benefit of this change

@jeanp413 Fair point 🤔 From my point of view, we already had inconsistency between gp-cli and JB IDEs having different thresholds [1], from a client perspective, it makes sense to me having only to map severity to color instead of value to color.

[jeanp413]

it makes sense to me having only to map severity to color instead of value to color

yeah I see that but that's more UI related so the API shouldn't be responsible of that.

Anyway if everybody else aproves just ignore my review 😄

[andreafalzetti]

Anyway if everybody else aproves just ignore my review 😄

It's important that everyone feels that we ship meaningful stuff :) This is a suggestion coming from @akosyakov, I found it valuable and we agred to work on it this week but it's important to challenge ideas so let's have a discussion with the other team members and let's take a decision.

I look forward to get feedback from @felladrin, @iQQBot, @mustard-mh, @loujaybee, @akosyakov :)

➡️ I don't mind closing this PR if we, as a team, decide that we want to keep the threshold values in each client instead of a single place (supervisor).

[akosyakov]

The main motivation is to having one place to control thresholds, not updating each client if we figure out that danger should .9 not .95.

[akosyakov]

it works as advertized, but we don't compute it in supervisor in all branches, see https://github.com/gitpod-io/gitpod/pull/12157/files#r947179792

/hold

[andreafalzetti]

/unhold