refactor post delete

[alphatownsman]

This PR moves most delete logic into Post.handle_deleted, and addresses the following issues of previous implementation:

• mass deletion was done in API request handler immediately, it can be really slow for a popular post in a large instance
• bookmark was still visible for 24 hr
• if a local identity boost a remote post, remote followers of this local identity may still see the boost of this post in their timeline (unless they are on the same instance of the author, or anyone on that instance follows the author)

For the last issue, this PR only UNDO the boost, but not forward the DELETE activity to remote instances bc it's too much work. Although both were done in Mastodon.

[dcwatson]

Why just these two types?

[dcwatson]

1. I'm on board with moving the deletes into a stator handler, but why the immediate partial delete vs. a full delete later? Some kind of client refresh timing thing?
2. Good catch about the bookmarks.
3. So this change does not fan out the delete to remote instances anymore? Was that intentional?

[alphatownsman]

I'm on board with moving the deletes into a stator handler, but why the immediate partial delete vs. a full delete later? Some kind of client refresh timing thing?

yep, just to make sure the author sees change immediately in case stator does not catch up fast enough; I added a comment for this but I'm ok to remove this hackish delete if you prefer.

So this change does not fan out the delete to remote instances anymore? Was that intentional?

Sorry, accidentally dropped that when copy paste from my production branch, should be good now