Check for unwanted subject deletion via set_member_subjects or subjects controllers

[lcjohnso]

Following on from #4250, this issue is to track this remaining open question from this comment:

[The fix for subject deletion via subject set deletion] will take care of this current issue. BUT what it does not take care of is if remover is called from SubjectsController or SetMemberSubjectsController, which if needed, will require a separate issue.

Subjects can still be deleted via the SubjectsController or SetMemberSubjectsController without any cross-SubjectSet or cross-Project checks. That may be OK / desired (i.e., if a research team removes an offensive image, it should be deleted everywhere), but uses of SetMemberSubjectsController.destroy should be checked.

More broadly: it would be helpful to document when/if subjects are checked before deletion, and how different routes use (or not) the can_be_removed? checks.

[lcjohnso]

Also related: it would be helpful to document cases where subjects are soft deleted (activated_state = 1) vs. hard deleted.

[Tooyosi]

From what I see, subject hard deletion is called from the cleanup method of Subjects::Remover.

This is however called from the destroy method in set_member_subjects_controller,subject_sets_controller,subjects_controller

The default behaviour of the controller (soft delete for subject_controller, hard delete on the resource for the others) occurs before hitting the SubjectRemovalWorker.perform_async method in each. Afterwards the logic to check if a subject can_be_removed? is checked within the cleanup method of the remover.

Summary: If the can_be_removed? evaluates to false for a subject deleted from the subjects_controller destroy method, the subject gets soft deleted however if it evaluates to true, it gets soft deleted(initially) and hard deleted from the Subject::Remover

cc @lcjohnso