feat(alarms): Introduce output type and its logic

[Ahalya-ni]

Pull Request

🤨 Rationale

Task 3513143: PR1 | Add Output Radio Group and its logic

This PR introduces output type control and its logic. This change is necessary because alarms count should be treated as an output type option (displaying properties vs. displaying total count) rather than a separate query type. This approach aligns with other datasources like Assets, Results, Test Plans, and Work Orders, which use total count as an output type to display the count.

A separate PR has been created to remove the alarms count query type and its related code throughout the alarms datasource. Here is the link to that PR.

👩‍💻 Implementation

• Added OutputType enum in the ListAlarms.types.ts.
• Introduced Output UI control of radio group type in ListAlarmsQueryEditor. Added in on change method to update the output type in the query.
• Updated ListAlarmsQueryEditor to show or hide the UI controls based on the output type selection.
• In ListAlarmsQueryHandler, I have refactored the runQuery by introducing private methods to handle the total count and properties queries separately. This makes the code cleaner and easier to debug.
• Copied the logic of calling the queryAlarms with the required fields for total count from AlarmsCountQueryHandler.

🧪 Testing

Added unit tests

✅ Checklist

• This PR has a title that follows the commit message format.

[Ahalya-ni]

This change is required to have less gap between the query type and output UI controls. This will affect AlarmsTrend editor gap between the query type and its query builder. Hence added Space from the grafana/ui to add appropriate space between the controls in Alarms Trend editor.

[manisha-ni]

Can you also add the screenshot of alarm trend editor so we can see the difference?

[Ahalya-ni]

Alarm Trend editor without Space

Alarm Trend editor with Space

[manisha-ni]

Other enums are using camelCase. Why do we need sentence case here?

[Ahalya-ni]

I have used Pascal case (TotalCount), not camelCase (totalCount), to match other UI oriented enums like QueryType.

[manisha-ni]

Can you also add the screenshot of alarm trend editor so we can see the difference?

[manisha-ni]

Do we really need this vertical space? I don't see this space in Assets

[Ahalya-ni]

Yes, in the Assets datasource, there's no gap between the Query type and Group by UI elements in Calibration Forecast. We have the same pattern in Alarms since both datasources have only one query type with an output control (List Assets in Assets datasource, List Alarms in Alarms datasource).

As I understand it, related controls are grouped together, while different functional sections are separated by gaps. In the Results datasource, we added a gap after the Output control, which works because both query types have output controls, maintaining consistency.

I've added a Space component to create a clear separation between the Query Type and query builder sections in the alarms trend workflow, following the mockup UI design specified in the HLD.

Leaving this comment open, to get @kartheeswaran-ni thoughts.

[manisha-ni]

Please update the description to explain why we need this change and also link the PR where the alarm count code will be removed