Ensure materialization_status has rows when task_log_history is empty

[joshelser]

Pull Request Template

Description

• Read from task_tables and left join against task_log_history (rather than the opposite)
• Fix the join condition and include warehouse_load_history to simplify
• Fix incorrectly reported NEXT_TYPE as being INCREMENTAL for null LAST_START case.
• Ensure a non-null NEXT_START time when missing LAST_CASE.

With this change:

>select user_schema, user_view, next_start, next_type, next_status from josh_opscenter_app.admin.materialization_status;
+-------------+-----------------------------------+-------------------------------+-----------+-------------+
| USER_SCHEMA | USER_VIEW                         | NEXT_START                    | NEXT_TYPE | NEXT_STATUS |
|-------------+-----------------------------------+-------------------------------+-----------+-------------|
| REPORTING   | DBT_HISTORY                       | 2024-05-14 11:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | ENRICHED_QUERY_HISTORY            | 2024-05-14 11:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | ENRICHED_QUERY_HISTORY_DAILY      | 2024-05-14 11:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | ENRICHED_QUERY_HISTORY_HOURLY     | 2024-05-14 11:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | LABELED_QUERY_HISTORY             | 2024-05-14 11:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | WAREHOUSE_DAILY_UTILIZATION       | 2024-05-14 11:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | WAREHOUSE_HOURLY_UTILIZATION      | 2024-05-14 11:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | HYBRID_TABLE_USAGE_HISTORY        | 2024-05-14 22:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | LOGIN_HISTORY                     | 2024-05-14 22:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | MATERIALIZED_VIEW_REFRESH_HISTORY | 2024-05-14 22:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | SERVERLESS_TASK_HISTORY           | 2024-05-14 22:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | SESSIONS                          | 2024-05-14 22:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | TASK_HISTORY                      | 2024-05-14 22:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | WAREHOUSE_METERING_HISTORY        | 2024-05-14 22:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | CLUSTER_SESSIONS                  | 2024-05-14 11:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | CLUSTER_SESSIONS_DAILY            | 2024-05-14 11:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | CLUSTER_SESSIONS_HOURLY           | 2024-05-14 11:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | WAREHOUSE_SESSIONS                | 2024-05-14 11:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | WAREHOUSE_SESSIONS_DAILY          | 2024-05-14 11:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | WAREHOUSE_SESSIONS_HOURLY         | 2024-05-14 11:43:38.294 -0700 | FULL      | SCHEDULED   |
| REPORTING   | WAREHOUSE_LOAD_HISTORY            | 2024-05-14 17:43:38.294 -0700 | FULL      | SCHEDULED   |
+-------------+-----------------------------------+-------------------------------+-----------+-------------+

Please include a summary of the change including relevant motivation and context.

Checklist:

• [x] I have verified that my change is functionally correct (unit tests are great).
• [x] Queries against newly-added, user-facing objects can be expected to complete in 1's of seconds.
• materialization_status view still is ~1s in execution time
• [x] My change will not have a substantial increase the user's cost to have the app installed (did you add any new tasks?).