Admin tools development/Global rename

Patch: 92468 Bug: 14862

Process:
 * When steward starts rename, centralauth.globaluser table is immediately updated. Jobs are queued on each wiki the account is attached.
 * If a user tries logging in to either the new name or old name, the login is rejected with an error message indicating the account is currently being renamed.
 * Once all local jobs finish running, the account is unlocked and the user can now login with the new account.
 * Note that the CentralAuth rename job calls the RenameUser class, which in turn spawns more jobs. So just because the CA job finished, doesn't mean all the revision/archive/etc. entries have been updated. However it is safe for the user to log in.
 * There will be some kind of special page where the rename progress is publicly visible.
 * There will be an option to move user pages or not, and to suppress redirects or not.
 * A log entry will be created on the wiki where the rename was submitted from. There will be no log entries locally except for any generated by page moves.

Backend:
 * When a steward starts the rename, a row for each wiki the user exists on is added into the centralauth.renameuser_status table.
 * When each local job starts, the row's status will change to "inprogress".
 * Each job starts the RenameuserSQL job on that wiki. It then moves all the user pages if that option was selected. We override the internal checks and assume that the steward is allowed to move pages/suppress redirects
 * When it finishes, it simply deletes the row. If for any reason it fails, the status is changed to "failed".
 * If it fails, this currently locks the user's account until a sysadmin intervenes. Needs to be fixed.
 * If a user tries logging in, we check for the presence of any row in the status table. If one exists, the login is aborted.

Concerns:
 * Current patch uses DB_MASTER nearly everywhere, including for read-only queries. Is that ok?