Cleanup post #2489

[lauriemerrell]

Description

Describe your changes and why you're making them. Please include the context, motivation, and relevant dependencies.

Resolves a whole bunch of issues that popped up after #2489 merged, primarily because of the larger time period of data covered in the full refresh compared to test data.

Specifically, this PR:

• Uses fallback to fct_daily_schedule_feeds for RT/schedule mapping for cases where the GTFS schedule URL changes and RT data is scraped before the GTFS schedule download occurs. This was indirectly causing CAL-ITP-DATA-INFRA-268M, CAL-ITP-DATA-INFRA-268R, and CAL-ITP-DATA-INFRA-2685 because of insufficient handling for multiple schedule URLs on the same dt/service date
• Prepares to add sampling to the testing on the intermediate tables here because these tables are large. Adjusts the sample to look at the 2AM UTC hour where bugs were occurring here; will only actually implement this once tests pass on whole tables in prod first (follow-up PR).
• Adds schedule_base64_url to the intermediate table keys; this may help with some of the duplicates that were observed (cases where a key was duplicated because the same trip occurred across two schedule URL versions)
• Adds forward-dating to the URL/Airtable mapper to handle gaps where RT data is downloaded from a URL that was deleted from Airtable in the gap before the new Airtable config is picked up. Uses this mapper to get Airtable records instead of joining directly.
• Deletes fct_daily_trip_update_status_counts model that was erroring and (per Slack) is ok to delete

Resolves #2802
Resolves #2803

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation

How has this been tested?

Include commands/logs/screenshots as relevant.

Ran all affected tables and tested them and downstream models.

Doing an unqualified run & test right now to confirm none of the fixed issues are present

Post-merge follow-ups

Document any actions that must be taken post-merge to deploy or otherwise implement the changes in this PR (for example, running a full refresh of some incremental model in dbt). If these actions will take more than a few hours after the merge or if they will be completed by someone other than the PR author, please create a dedicated follow-up issue and link it here to track resolution.

• No action required
• Actions required (specified below)

• Full refresh +fct_trip_updates_messages+ +fct_vehicle_positions_messages+ +fct_service_alerts_messages+ to get the fixed keying
• Follow-up PR to uncomment sampled testing on the intermediate models once they are passing

[atvaccaro]

discussed offline

[lauriemerrell]

dbt run / test (unqualified) passed with no new failures (all failures predate #2489). Merging and kicking off full refresh