resend all past webmentions from newly blocked users

[snarfed]

split out of #473. bridgy will 410 the source mf2 pages for those past responses, so this will let the target site delete them if it wants.

a naive implementation here isn't too hard, but scaling it will take a bit of work, since bridgy could have sent an arbitrary number of wms to a given user before they were blocked. we'd need a new task queue and implementation that shards past wms across tasks.

more importantly though, this would create a user-visible promise (if implicit) that bridgy keeps all past wms it's ever sent. it does now, but i don't know if i want to guarantee that going forward. i could document that it might only resend some wms from newly blocked users, but that gets complicated, and will still surprise users when newer wms get deleted but older ones persist.

soooo...i'm unlikely to do this any time soon. i'll happily review a PR that implements it! but no promises on merging.

the alternative here is to let wm receivers filter wms dynamically, at render time. e.g. aaronpk/webmention.io#85. granary supports this by fetching twitter block lists and serving them as mf2, etc. via REST API.

cc @tantek @aaronpk

[aaronpk]

I totally understand not wanting to promise that Bridgy will keep all past webmentions. I think keeping Bridgy as a transport tool is good, and leave those kinds of promises for things like webmention.io which are specifically built to store all your webmentions.

[snarfed]

i'm doing a sweep and closing issues that i don't plan to do myself or accept a PR for, including this one. apologies for the bad news, or if this is a surprise. feel free to reopen if you feel strongly.