feat(ingestion): allow cause_detail and effect_detail to be Translations

[runkelcorey]

🔔 handle new & old schemas when ingesting alerts

What changes does this PR propose?

Implements temporary logic until Alerts Manager changes schema that

1. allows for cause_detail and effect_detail to either be strings or Translations
2. regardless of the input, outputs a table with
   • cause_detail.translation
   • effect_detail.translation
   • cause_detail
   • effect_detail

Not in scope for this PR is updates to performance manager to actually read the English translations from Alerts in the new schema.

How were these changes validated?

1. Updated PM alerts test to ensure that these additions wouldn't cause problems for PM
2. Adds ingestion test to check what happens if data with the new schema is appended to data with the old schema
3. Soaking in dev w/o errors
4. No PM Alerts errors in dev

What questions should reviewers consider?

1. Are you okay with this so long as I create a ticket to clean it up after migration?

[github-actions]

LCOV of commit 05e19ae during Continuous Integration (Python) #1993

Summary coverage rate:
  lines......: 64.7% (3596 of 5558 lines)
  functions..: 29.9% (275 of 920 functions)
  branches...: no data found

Files changed coverage rate:
                                                                                     |Lines       |Functions  |Branches    
  Filename                                                                           |Rate     Num|Rate    Num|Rate     Num
  =========================================================================================================================
  src/lamp_py/ingestion/config_rt_alerts.py                                          |98.2%     56|41.7%    12|    -      0
  src/lamp_py/ingestion/convert_gtfs_rt.py                                           |88.4%    242|50.0%    26|    -      0

[huangh]

looks reasonable - decide if any of my comments are valid or if you can live with it - i think the only consequential change would be to further flatten the translation.language out, but if you've already been testing and are okay with the ergonomics of it, it's not a dealbreaker for me.

i could see arguments against doing what i suggested..

[github-actions]

LCOV of commit 78f2d38 during Continuous Integration (Python) #1994

Summary coverage rate:
  lines......: 64.7% (3596 of 5558 lines)
  functions..: 29.9% (275 of 920 functions)
  branches...: no data found

Files changed coverage rate:
                                                                                     |Lines       |Functions  |Branches    
  Filename                                                                           |Rate     Num|Rate    Num|Rate     Num
  =========================================================================================================================
  src/lamp_py/ingestion/config_rt_alerts.py                                          |98.2%     56|41.7%    12|    -      0
  src/lamp_py/ingestion/convert_gtfs_rt.py                                           |88.4%    242|50.0%    26|    -      0
  src/lamp_py/ingestion/gtfs_rt_structs.py                                           | 100%      6|    -     0|    -      0

[huangh]

lgtm. last thing non-blocking- should we have some sort of logging when the schema gets expanded or some new input comes in? we want to know that it's happened and perhaps adjust the default schema of record to incude these changes eventually? otherwise our documented dataframely definitions will get outdated.