feat(bus): Keep original values for gtfs_arrival_dt and gtfs_departure_dt

[runkelcorey]

Working group needs to be able to reconstruct the stop_arrival_dt and stop_departure_dt from its components.

What changes does this PR propose?

Refactors to defer creating stop_arrival_dt and stop_departure_dt until the last stage.

How were these changes validated?

1. Moved and updated tests
2. Ran bus runner locally

What questions should reviewers consider?

None.

[github-actions]

LCOV of commit 0cf1d44 during Continuous Integration (Python) #2066

Summary coverage rate:
  lines......: 64.6% (3606 of 5582 lines)
  functions..: 29.9% (276 of 924 functions)
  branches...: no data found

Files changed coverage rate:
                                                                                     |Lines       |Functions  |Branches    
  Filename                                                                           |Rate     Num|Rate    Num|Rate     Num
  =========================================================================================================================
  src/lamp_py/bus_performance_manager/events_gtfs_rt.py                              |85.5%     76|44.4%    18|    -      0
  src/lamp_py/bus_performance_manager/events_joined.py                               |76.3%     59|28.6%    14|    -      0
  src/lamp_py/bus_performance_manager/events_metrics.py                              |68.9%     61|35.7%    14|    -      0
  src/lamp_py/runtime_utils/remote_files.py                                          | 100%     78|50.0%     6|    -      0

[mreginald]

Hi @runkelcorey, I hope that orientation went well! We tried to do an assessment of the potential changes by comparing staging to prod, and I think a middle ground would be the most useful thing for us to have to test, but we aren't ready to move this proposal into prod yet.

When you're back, can you please put the following changes into staging for midpoints (lines 225 to 232), so that the stop_departure_dt is the result of coalescing:

1. min_horizontal(tm_actual_departure_dt, gtfs_departure_dt)
2. the next gtfs_first_in_transit_dt (exactly what's in lines 230 to 232, but this is what would be coalesced, instead of including this in the previous step where you take the earliest of the various timestamps.

We did some analysis we can talk more about next week, and in the cases where there actually IS a tm_actual_departure or a gtfs_departure_dt, taking the next stop's gtfs_first_in_transit_dt reduced accuracy, so we want to test out just having this be a fallback when the data is null, instead of treating it as one of the equally viable options in the min_horizontal step.

3. gtfs_last_in_transit_dt NOT gtfs_first_in_transit_dt (the final option for the coalesce in line 234)

The final fallback for the stop departure should be the last in_transit_to record approaching the stop instead of the first recorded timestamp approaching the stop

Let me know if you want to huddle about any of these proposals before implementing!