feat: add indicator when there is an error with per-check alerts

[VikaCep]

Closes #1131

With the new per-check alerts, the creation request can be successful but there can still be asynchronous errors that need to be displayed to the user. This PR addresses this requirement.

From https://github.com/grafana/synthetic-monitoring/issues/266:

Alert rules creation process is performed asynchronously from the HTTP request that triggers its creation. This means that the user might have received a successful response (202 HTTP Accepted), but the rule itself might not end up being created (for example due to quota limits or other possible errors).
The backend registers the possible errors returned from Hosted Grafana. We should expose these errors to the plugin, so the plugin can take different actions in order to try to provide feedback to the user on that situation. Possible methods discussed are:

• Error indication on the check list:

• Error indication in the check form - Alerting section:

NOTE: in order to see the error messages, the app can be started using yarn dev:msw where there is a check (Job name for http) that provides an error for the TLSTargetCertificateCloseToExpiring alert

[ka3de]

I was a little bit confused because I see that we are showing the error next to the alert in the "alerts pop-up". But IIRC, this alerts pop-up is populated from the alerts that are already created, because these are queried through some alerting endpoint.

So how are we doing that for the case on which an alert has been set up for a check, but this one is not created in the stack, for example due to a quota limit error?
The folder name is static for all SM alerts, and the check alerts data provides the alert name and period, but the group name is still missing... I believe we have a mapping for alert name - group name in the plugin which we use, along with the period (if applies), to build the group name and show all that information even if the rule does not exist?

[VikaCep]

You have a good point. I made some changes so now the UI always displays per-check alerts, even if the corresponding alert rule does not exist in the alerting endpoint response.
Basically, for each alert configured on a check, it now attempts to find the matching rule in the alerting response. If it is missing, a local “dummy” group is constructed with the appropriate category and default values, ensuring the alert (and any error/status) is still shown in the alerts pop-up. The folder UID is static for all SM alerts, and the group/category is determined from the predefined alert mapping.

In the screenshot below, the TLSTargetCertificateCloseToExpiring alert is shown from the alerts API response as it's not returned from the alerting endpoint. I just had to hide the "view" icon link as there is no place to link it if it doesn't exist. Does this sound good to you?

[ka3de]

Does this sound good to you?

That looks great! Thanks 🙌

[ckbedwell]

LGTM