Back out deletion of submissions when a source is deleted

[redshiftzero]

Status

Ready for review

Description of Changes

This was a addition in #1440, but similarly to #1671 until we have a migration path
for making changes like this to the database we cannot ship this yet
to instances (it adds an ON DELETE CASCADE constraint).

Pushed to 0.4.x release series.

Added to checklist in #1658.

Testing

1. Provision dev VM.
2. Make sure dev tests pass locally.

Checklist

If you made changes to the app code:

• Unit and functional tests pass on the development VM

[redshiftzero]

Hmm, so I just read about how SQLAlchemy does this a little more, and it looks like this might actually be done in the ORM and so okay to leave in. From the docs:

The behavior of SQLAlchemy’s “delete” cascade has a lot of overlap with the ON DELETE CASCADE feature of a database foreign key, as well as with that of the ON DELETE SET NULL foreign key setting when “delete” cascade is not specified. Database level “ON DELETE” cascades are specific to the “FOREIGN KEY” construct of the relational database; SQLAlchemy allows configuration of these schema-level constructs at the DDL level using options on ForeignKeyConstraint which are described at ON UPDATE and ON DELETE.

But for safety, need to test the upgrade to check that there isn't an unforeseen issue here.

[redshiftzero]

Yeah, in further digging around on how this is done in SQLAlchemy, this is indeed ORM only. In order to set ON DELETE CASCADE one has to explicitly set the ForeignKeyConstraint. So! We can leave this in and I'm closing this PR.

[conorsch]

Manual testing of the upgrade strategy here went well, so agreed we can close. Even when this feature lands, it'll only help for future delete actions. We should consider cleaning up dangling database references in a future migration.

[redshiftzero]

Yep, totally. We have the cleanup still to do in issue #1189.