engine/metricsmanager: add daily_alert_metrics table

[dctalbot]

• Identified the issue which this PR solves.
• Read the CONTRIBUTING document.
• Code builds clean without any errors or warnings.
• Added appropriate tests for any new functionality.
• All new and existing tests passed.
• Added comments in the code, where necessary.
• Ran make check to catch common errors. Fixed any that came up.

Description:
This PR adds a new daily_alert_metrics table that aggregates metrics from alert_metrics. We do this basically as a cacheing strategy for the metrics API targets.

How to test:

1. make regendb
2. make start
3. Watch engine_processing_versions.state update where type_id = 'metrics'
4. The state's LastMetricsDate will never exceed the date of LastLogTime. Therefore, to get metrics for the current day, one must look in alert_metrics.
5. Observe rows being added in alert_metrics and daily_alert_metrics over time.

Which issue(s) this PR fixes:
Closes #2122

Additional Information:
This PR modifies the local dev alert generation to be spread across the previous 30 days as opposed to 2 hours. This makes testing more interesting and realistic.

[Forfold]

I see LastLogTime slowly incrementing in time as I refresh the db, is this because it's trying to catch up on alerts until it gets to today?

[dctalbot]

@Forfold Yep, that's spot on. At the same time, LastMetricsDate will keep incrementing until it reaches LastLogTime