Change move handler to carry blocks over

[ClearlyClaire]

When user A blocks (or mutes) user B and B moves to a new account C, make A block (or mute) C accordingly.

Note that it only works if A's instance is aware of the Move, (that is, if B is on A's instance or has followers there, or, if we accept the following change, the person has actually sent a Block activity).

This is to reduce the odds of people making accidentally “evading” blocks by moving to a new account (of course, this doesn't prevent malicious users from creating accounts that are not linked with the blocked ones).

I am not sure if there is any downside to this (except, in the case of blocks, sending Block activities, which technically notifies the blocked user, but they would know already, and that's an issue with blocks anyway—stealth blocks would solve this and are not incompatible with this feature).

Also extended the ActivityPub::MoveDistributionWorker to send the Move activity to people who issued a Block activity about that person (this means it wouldn't be as reliable with stealth block, but that's a best-effort thing anyway).

[ClearlyClaire]

I added a commit to exempt target account from carrying over mute/block if they're followed by the blocking/muting person, because I think having a person your follow disappear/be blocked for seemingly no reason may be too surprising (e.g. blocking someone you've made amends with and started following again on their new account, if they officially Move to it later).

[ClearlyClaire]

I have been told that such a change may lead to confusing blocks/mutes for end-users, and that a note/explanation would help alleviate that.

We could do that by either adding a free-form text field (that would also be useful for people to make note of why they blocked/muted someone) that would be pre-filled with an explanation, or just record the previous handle to clearly display the user the block was automatic and who was targeted in the first place.

The second option would be easier to implement and design, especially as far as i18n is involved, but it would add a database column that would have no other use. The first option would be more involved, especially design-wise, but it would be useful for other reasons as well.

None of those options seem required for the discussed feature to be merged, but they would be useful.

[ClearlyClaire]

If #14148 gets merged, the move handler can be changed to copy over the block/mute reason, prefixed by something along the lines of “This person has been automatically blocked, because you have blocked their former account foo@bar.”

[ClearlyClaire]

Changed it to make use of #14148 to create a note containing “This user moved from foo@bar, which you had blocked.” if you had blocked the source account (but had not set a note), and “This user moved from foo@bar, which you had muted.” if you had muted the source account (but not blocked it nor set a note).

The rationale behind not adding both lines and not adding any of the lines if a user note existed is that if a user note existed already, it includes information about the account moving already (thanks to copy_account_notes!), as well as, probably, some information about the block. So we'd avoid prepending duplicated information that way.