🐛 Use pg cascade delete on delete study resource

[znatty22]

Partially addresses #329, read below

Problem

Deleting a single study takes so long that it times out before the delete is complete and the API returns a 503. This is because the request timeout on the webserver (gunicorn) is set to 30 sec. The deletion of a study takes longer than 30 sec (Chung takes ~2.5 minutes) because of two problems 1) a study has large tree of related entities and the dataservice is currently using the ORM to do a cascading delete of this large tree. 2) Genomic files and study files must also be deleted in the indexd service. This also takes minutes complete. Chung takes ~1.5 minutes just to delete genomic files from indexd.

Solution

This PR addresses bottleneck 1 above by deleting a study more efficiently using Postgres's cascading delete rather than the ORM's cascading delete. We may need to address bottleneck 2 by making delete study a background/long running task. We can do this either in this PR or another PR.

After implementing postgres cascading deletes, Chung takes ~1 seconds to be deleted. This does NOT include deleting indexd records from the indexd service.

• Add ondelete=CASCADE to foreign keys
• Update DELETE /studies/<kf_id> logic
  -- Delete study's genomic files from indexd
  -- Use db's cascading delete instead of the ORMs cascading delete

[fiendish]

What ever happened to this? Especially in relation to the many thousands of requests needed for https://github.com/kids-first/kf-utils-python/blob/master/kf_utils/dataservice/delete.py

[znatty22]

@fiendish I think the reason we didn't merge is bc we ultimately decided we don't want to make deleting studies that easy?

[fiendish]

lololol