Update queries for workflow classification counts - attempt to optimize workflow classification count performance

[yuenmichelle1]

Because of how the FE calls out /classifications?workflow_id endpoint when querying from project's stats (i.e. all at once), which is hammering the API and Timescale db. 🔨

This ^ (and our non-usage of compression or data retention policies) plus our usage of Real Time Aggregates on the continuous aggregate we query workflow data from, causes querying to be not performant. (As evident when turning off Real Time Aggregation, we see faster query times and lower cpu utilization).

Because we are limited in resources and we still want Real Time Aggregation to be possible, we do the following for querying workflow classification counts ONLY:

• Create a New HourlyClassificationCountByWorkflow RealTime Aggregate
• Set a data retention policy for this new hourly workflow classification count aggregate (this should limit the amount of data the query planner will have to sift through when dealing with real time aggregates)
• Turn off real time aggregation for the DailyClassificationCount
• When querying workflow classification counts that include current date's counts, we query current date's counts via the HourlyClassificationCountByWorkflow continuous aggregate and we query the materialized DailyClassificationCountsByWorkflow for everything before that date

[hound]

Style/FrozenStringLiteralComment: Missing magic comment # frozen_string_literal: true.