Improve Query compactness / naming conventions / styling

[diego-escobedo]

Currently, we have all the queries that power our metric aggregation stored in backend/metering_billing/aggregation. Though they are functionally working, there are some things worth considering and possibly fixing:

1. We are using jinja to template the queries and insert external variables. Is this the best tool for the job? Can we tidy up how the jinja renders the queries and enforce consistent styles (when inspecting queries there's a ton of funky looking whitespace)?
2. Is storing the queries as a string the best idea? Have no way of linting/formatting/checking the queries easily.
3. Can we identify ways to extract "common" snippets and turn them into stored procedures or find a way to combine the snippets as needed into a full fledged query? For example, we have the exact same statements used to identify the top_n customers in the total_daily_usage queries across counter, gauge, ands rate metrics.
4. We should decide on naming conventions: e.g. sometimes we call the time time_bucket, or time, or time_created. For similar concepts in queries across the files, we should enforce consistent naming.

If anyone wants to tackle one of these 4 / look into them and come up with a plan of action, might be a good idea to spin them out into their own issue.

[sharonwoo]

Is storing the queries as a string the best idea? Have no way of linting/formatting/checking the queries easily.

Borrowing an idea from analytics warehouses, typically queries themselves are stored in separate files (if in SQL, then .sql), then imported. This makes them easier to keep track of and see changes just to the queries over time, and makes possible linting just the queries and enforcing style formats.