Remove emergency alerts code

[leohemsted]

This doesn't deal with any database migration, but it does get rid of all code.

TODO before we merge:

• check nothing in admin app will break. for example, what happens with existing older broadcast templates? do they still exist, are they viewable? will they break if you go view them?
• check nothing with redis will break
• figure out what to do with broadcast data in the db. especially tables that are used for other things (eg templates, services, etc)

---

• delete data (Remove emergency alerts data #4201)
• clear redis
• delete models 🚨 you are here 🚨
• delete db tables/types/etc entirely (Remove emergency alerts db schema #4202)

[quis]

At the moment if you try to view a broadcast template in the admin app you will get an exception (the app doesn’t know how to preview one of these templates).

But the only way you can get to that page is by manually entering the id of the template in the URL. You can’t see a list of those templates on the templates page for example. I don’t think this PR will change that behaviour, so I don’t think handling it needs to be a blocker to merging.

We could put in a workaround to return a 404. Or we could do a migration later on to delete all broadcast templates.

[leohemsted]

i think to start with we could put 404s on any broadcast template or broadcast service endpoint, and then delete the data later

i'd be keen on deleting the data in the DB earlier rather than later so we dont get surprised by weird data if we want to update schemas on those tables or migrate data based on columns listed in the models or things like that

[idavidmcdonald]

FYI, we can't delete any of the broadcast data out of our database for 1 year please. Either that or we need to take a snapshot of that data and store it elsewhere for a year. This is because emergency alerts need it as an audit trail for any security incidents (precedent is to store it for a year, just like Notify does).

The 1 year is from the time they migrated to their own system (was that like early November maybe?)

[leohemsted]

thanks, that's useful to know david. I'd probably be keen on snapshotting and storing it in a pgdump in s3 ideally

[klssmith]

This has been checked and rebased to get rid of merge conflicts. The data has been deleted, so the comments relating to that no longer apply.

The failure of the migration-isolation-check ("Please separate migration changes from other code changes into separate PRs. This helps ensure safer deployments and easier rollbacks if needed") is fine - we're only removing a couple of unused imports from the migration files, not making any database changes.