Avoid warning fatigue

[jhrv]

Today we flag every application with a "issue" as yellow and a warning sign, resulting in a daunting amount of yellowness causing fatigue.
Many of the kind of warnings we give, is things that we don't have any real push behind. It's not actually important, but just nice if they fix. Examples of this is deprecated ingresses, images repositories etc.

We should make them aware of this, but change the wording and visual significance that this has - to better be able to highlight what is actually important and critical that they fix. A better word for this category might be "Todo", "Notification", "Remark". "Something to be aware of and fix when you have the spare time, because it might be deprecated harder in the future"

These issues should still be viewable on the application page as a separate tab, like today - as well as a aggregated list of issues for the team on the team page.

[tronghn]

More examples: missing outbound rules for applications.

• https://nav-it.slack.com/archives/C5KUST8N6/p1701082885188839
• https://nav-it.slack.com/archives/C5KUST8N6/p1702383584277669

Today, the access policy block configures both application/token auth in addition to network policies. The former does not concern itself with outbound rules at all, and thus these warnings are misleading for applications that only need auth without performing service discovery calls.

[jhrv]

@thokra-nav did you have any comments on this?

[thokra-nav]

Yeah, mostly that I do think deprecated ingresses etc should be a proper warning and not hidden as something else. But we should also have a turn off date or something similar when we consider something as deprecated.

So I do like what someone mentioned, a best practices checklist for things we consider bad practice, want to reduce usage of, but haven't set a deadline for (so not really deprecated).

[Starefossen]

GHCR registry warning should be hidden as well imho.