Ability to transfer channel membership between homeservers

Nobody has claimed this yet.

I'm considering this distinct to https://github.com/matrix-org/GSoC/blob/master/IDEAS.md#decentralised-accounts because it is not as complex to implement.
The general idea is that I might want to move from @caleb:HomeserverA to @cjd:HomeserverB and while I accept that my handle will change, I would like to swap my new user into all of the channels and private messages which my old user was in and when I switch, I would like to keep my backscroll.

To bound the scope of this proposal:
* Name change is expected, this is not about making a global p2p nickname namespace
* Both involved homeservers are willing to perform the transfer

How the workflow might work:
1. On the old homeserver, In your user settings, next to "disable account" there is "transfer account", which also shows a warning because it is also permanent, after you click this button, you enter the new id to transfer to (which should already be registered with the new homeserver).
2. It produces for you a block of base64 which contains the new name and a signature authorising the shift, the user copies this.
3. User logs into the new homeserver and goes to settings and clicks "import account" and pastes the base64 code.
4. After verifying, the new homeserver broadcasts a transfer message to the network, this message contains the authorization to transfer from the old homeserver and so it is signed by both old and new.
5. Receiving a transfer message, all homeservers find-and-replace the old user with the new one in the db.
6. New homeserver begins to synchronize history of all of the channels joined from the old one. OR downloads them from the old homeserver through some special api...

Notes:
* base64 blob and new homeserver name constitute 2 factor auth for transfer, this helps mitigate the risk that someone accidentally transfers to the wrong account (not theirs).
* Transfers must be accepted, otherwise they can be used to "invite" people to zillions of channels
* Transferring username and image are a "nice to have" but definitely not required.

The issue describes a proposed account-transfer workflow but names no implementation files, tests, or existing entry points. Start by locating the specification's account, room-membership, and history-synchronization sections, then determine whether the transfer protocol and its security and migration behavior are defined. Done means the scope and protocol design are agreed and reflected in the relevant specification sections.

Written by the indexing model from the issue text.