Add server-side downsampling/aggregation for Dashboard widget time range selection

[kruscho]

Hi,

i just want to discuss this feature request with you guys:

Description

Dashboard widgets already support selecting a time range per widget. However, this time range selection is currently coupled to a fixed, pre-configured number of data points in the widget settings, rather than to the actual selected time range.

In practice, this means:

• If a user selects a long time range (e.g. 7 days) on a widget configured for a small number of data points, they only see a small, arbitrarily truncated/sampled slice of that range — not a representative view of the whole period.
• If a user selects a short time range on a widget configured for a large number of data points, the widget may try to fetch/render far more raw points than necessary, which is slow and can freeze the browser tab.
• There's no aggregation happening based on the selected range — the "amount of data points" setting acts as a static cap rather than a dynamic resolution based on the time window.

Expected Behavior

• The number of data points shown in a widget should scale with the selected time range, not be a fixed static value defined once in the widget config.
• Data should be downsampled/aggregated server-side (e.g. time-bucketed min/max/avg per bucket) similar to the aggregation already available in the Data Explorer, so that widgets remain fast and responsive regardless of how large a range is selected.
• The widget configuration could define a target resolution (e.g. max points per widget, or bucket size relative to widget width) instead of a fixed absolute point count, so the backend can compute appropriate aggregation buckets for whatever range the user picks at runtime.

Motivation / Use Cases

• Users frequently want to inspect longer time ranges (e.g. a full shift, day, or week) directly from the dashboard's time range selector, but currently either get a misleading truncated view or a slow/unresponsive widget.
• Aligns dashboard widget behavior with the Data Explorer, which already performs aggregation queries against the data lake — this capability should be reused rather than re-implemented.
• Reduces the need for users to manually guess and re-tune the "number of data points" setting for every widget/range combination.

Suggested Implementation Notes

• Backend: extend/reuse the existing Data Explorer aggregation query API to support widget queries with a timeRange + targetResolution/maxDataPoints parameter, computing bucket size dynamically (e.g. bucketSize = rangeDuration / maxDataPoints).
• Frontend: when the user changes the time range via the per-widget time selector, recompute and pass the appropriate aggregation parameters to the widget's data request instead of relying solely on the static configured point count.
• Consider sensible defaults (e.g. cap total points per widget at ~500–1000) so widgets stay responsive across both short and long selected ranges.
• Verify consistent behavior across all chart/widget types that support the time range selector.

Acceptance Criteria

• Selecting a longer time range on a widget results in properly aggregated/downsampled data covering the full range, not a truncated slice.
• Selecting a shorter time range does not over-fetch unnecessary raw points.
• Widget rendering performance stays acceptable across small and large time ranges.
• Existing "number of data points" widget setting is replaced by (or reinterpreted as) a resolution/target-point parameter used for dynamic aggregation.
• Behavior verified across supported widget/chart types and Kiosk Mode.