Preserve old CR3 metadata when CRIS updates a crash

[johnclary]

Associated issues

• https://github.com/cityofaustin/atd-data-tech/issues/16684

Testing

I'm not sure what the best way is to test the CRIS import ETL. Looking for guidance here :)

---

Ship list

• [ ] Check migrations for any conflicts with latest migrations in master branch
• [ ] Confirm Hasura role permissions for necessary access
• [ ] Code reviewed
• [ ] Product manager approved

[frankhereford]

~Hi John, thank you for looking into how we can limit the number of CR3s we have to download. It's a bunch, no question.~

~How does this know when a crash has been meaningfully updated? I totally get that a huge number of the crashes that we're receiving right now are due to reprocessing, but there are still the normal volume of crashes which are getting normal updates.~

Never mind! I had the wrong idea about the intent of this PR and my question above was 100% ill-informed. When I reviewed the issue itself, this all came together for me. Thank you for working to keep the CR3s available to the end user, which is 100% a better behavior.

Here's the query that the downloader uses, and all that really matters is that the cr3_stored_flag is set to N which is happening just like it always has. This is 👍 in terms of this edit to this script.

Also, thank you to Mike for asking good questions to help ensure all the parts of the stack stay in concert with each other. 🙏

Thanks!