Improve handling of deleting users with thousands of posts.

Trying to clean up some spam user accounts which flooded my forum, I ran into several issues when trying to remove these spam accounts and selecting to also delete their posts in the user administration panel.

Note that these users had around 8k-25k posts.

Examples of how the issue is experienced by users (depending on the environment) after confirming the deletion of the user:

• white page of death (with no hint in the php error log on what went wrong)
• "MySQL server has gone away [2006]" output
• huge delay (up to more than an hour where the confirmation dialog stays on screen)

After a day's work I traced down the problem to be caused by the pure amount of posts these users had and the way phpbb is handling the deletion of these requests. Ultimately I figured out that the WpoD is caused by php running out of the max memory (was 128 MB - increased to 1GB solved the issue) and the MySQL server errror 2006 being caused by phpBB creating a deletion query which is larger than the max-package-size set up in MySQL (fixed by raising the package size limit from 16 MB to 32 MB).

I certainly understand that this is quite an exceptional use-case of deleting users with so many posts, still I would have assumed that phpBB handles this more performant/reasonable and don't create a single huge SQL statement which is consuming so much memory/CPU cycles. Can't this be somehow improved?

At the very least I'd imagine a big warning showing up, if the user/admin tries to remove user accounts which >500-1000 posts, making him aware of the possible failure of the operation.

Better of course would be to one way or the other split up the operation in multiple chunks (f.e. per cycle remove only 500-1000 posts).