deleting an item does not remove its copy tags

Confirmed on EG 3-2-0

I have a branch that works for me in removing item tag mappings upon item deletion:

https://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/csharp/lp1761615_delete_copy_tags_on_copy_delete

To test:
1) add copy tags to an item
2) verify from the database end that the copy tags were created (asset.copy_tag) and mapped (asset.copy_tag_copy_map).
3) delete the item - you will see the asset.copy_tag_copy_map rows still in place
4) apply this fix
5) repeat steps 1-3 and verify that the asset.copy_tag_copy_map rows are now gone.

I have tested this code and consent to signing off on it with my name, Beth Willis and my email address, <email address hidden>.

Noting that the rest of the item deletion code intentionally does _not_ cascade deletes to things like alerts, statistical categories, and notes so that they remain available for reporting purpose and revival if the item gets undeleted.

Consequently, would an suitable alternative be making catalog search ignore deleted items and call numbers when searching on item tag?

Given the philosophy (or habit) in Evergreen of not deleting when not necessary I think we should be consistent and not actually delete tags. Suppressing them from search and display is a better path I think.

Removing pullrequest pending resolution on discussion.

I agree with Rogan's comment--I think we should be consistent. It makes more sense to me to suppress them from search and display. It also seems like it would be useful to have those reportable even after the copy is deleted. Jason's parentheses note seems like the real bug, IMO.

I agree as well -- search is the problem, and depending on how these tags are used, these could be useful in reports to see, for example, all the books that were donated by the Professor Plum Foundation, including ones no longer in the collection.