Limit the number of concurrent restarts when nuking, or spawn each restart as a separate task

[Carnagion]

Currently, when executing /registration nuke, every user's registration is restarted concurrently, on the same tokio task (which is spawned by poise and serenity when handling the command).

However, when restarting the registrations of hundreds of users, the high number of incoming and outgoing Discord websocket requests and database connections, combined with the insufficient database connection limit, leads to the operations being performed inconsistently.

This might be solved in one of three ways:

• Limit the number of concurrent restarts to prevent situations where the database cannot handle the sheer number of connections
• Perform each restart in a separate tokio task, possibly combined with the above, to introduce some leeway for parallelism and avoid excessive load on one task
• Restart registrations sequentially rather that concurrently to provide more predictable and consistent behaviour

[Carnagion]

As a temporary solution, the number of concurrent restarts has been limited to 10 - its original value before I removed the limit. See 68e5331.

A more permanent and well-thought out solution should be worked on and tested as soon as possible.

[Carnagion]

Limiting the number of concurrent restarts has shown itself to be a good enough solution for now, as it was able to nuke upwards of 50 users under 12 minutes.

Since registration nukes are usually rare, one-time events, I believe this will work as a fairly permanent solution. In the unlikely case that a future nuke involves hundreds of students or more, it might be worth implementing one of the other solutions from #2.