Add a transaction around `move_issues_to_ghost_user`
What does this MR do?
- When a user is destroyed, their dependent issues are moved to a ghost user to prevent these issues from being destroyed.
- Before moving the issues, the usere is blocked, to prevent a data race.
- Previously, if the issue migration failed for some reason (we saw a deadlock), the user block was not rolled back.
- We fix this by running the entire process in a transaction.
Why was this MR needed?
When issue migration to the ghost user fails during user deletion due to a deadlock (or any other reason, presumably), the usere stays blocked
What are the relevant issue numbers?
- Related to #30306 (closed)