[feature] Process outgoing Move from clientAPI

[tsmethurst]

Description

If this is a code change, please include a summary of what you've coded, and link to the issue(s) it closes/implements.

If this is a documentation change, please briefly describe what you've changed and why.

This pull request implements actual processing functionality for accounts Moving via the GtS client API:

• Federate Move activity out when a valid Move has been submitted via the API.
• Process local side effects of a Move (redirect local followers to new target).
• Prevent Moved local accounts from taking most write/create style actions via the client API.
• Document the Move procedure.
• Indicate on the web frontend if an account has moved (see image).

Relates to #130

Checklist

Please put an x inside each checkbox to indicate that you've read and followed it: [ ] -> [x]

If this is a documentation change, only the first checkbox must be filled (you can delete the others if you want).

• I/we have read the GoToSocial contribution guidelines.
• I/we have discussed the proposed changes already, either in an issue on the repository, or in the Matrix chat.
• I/we have not leveraged AI to create the proposed changes.
• I/we have performed a self-review of added code.
• I/we have written code that is legible and maintainable by others.
• I/we have commented the added code, particularly in hard-to-understand areas.
• I/we have made any necessary changes to documentation.
• I/we have added tests that cover new code.
• I/we have run tests and they pass locally with the changes.
• I/we have run go fmt ./... and golangci-lint run.

[daenney]

Did a quick first pass. Things look pretty sensible and the client API side looks a lot less complicated.

[daenney]

Since you can't really move to an http URL, as the whole fedi requires TLS, should we check it against config.GetProtocol instead? In case you're running in test mode or something. GenerateURIForMove also uses config.GetProtocol.

[NyaaaWhatsUpDoc]

i think doing this would actually break some of our tests (as we use a mix of http / https test domains).

honestly i don't think it's much of an attack vector (if any), and the check will be faster this way than going through a read mutex lock

[tsmethurst]

I will leave this for now, but perhaps we can make a separate issue to better support http-only local testing, since similar discussions have happened elsewhere too.