Add cascade delete constraints, allow users to delete their accounts

[DasSkelett]

Motivation

Every now and then users want to delete their accounts (we should ask for the reason the next time, out of interest).
Every website with the option to create accounts should (and also must) have another option to delete these accounts again.

How and what

There's still the discussion on what we actually want to delete if a user deletes their account.

For know, to get us started, I decided to stay consistent with what we already do and delete everything linked to that user, both in the database and on disk. This means mods of these users are deleted too.

Please continue this discussion in #215 or on the Discord and leave the comments on this PR to actual code review.
I'll update this PR depending on how we decide on that.

Changes

• If the user's session cookie has an invalid game id (e.g. if the game has been deleted after it has been set in the cookie) _restore_game_info() threw an exception. Now it returns None.
• Some database magic: Added cascade delete constraints to all the relationships / foreign key constraints where it makes sense. This simplifies the deletion of mods (and also deletes some stuff we forgot until now, like download events and follow events), and enables the deletion of user accounts. It'll likely help us in the future too.
  This needs a database migration.
• Based on this, I added an option for users to delete their accounts in the profile edit page. There's not much to it, I've mostly copied the code from the password change option where possible. To prevent some unfortunate mouse clicks having a devastating effect, you have to enter your username to confirm the deletion.
• Admins can also delete users, on the user profile page (where all the other per-user admin infos and options are)

Closes #215

[HebaruSan]

What remains to be done here? Do we just need a final decision on what should be deleted, or are there code pieces left?

[DasSkelett]

Hm, can't really remember the technical points, maybe the deletion of zips when individual mod versions are deleted had still to be done.
It was mostly the discussion about what to delete that I didn't want to bring up again that kept this WIP.

[HebaruSan]

It was mostly the discussion about what to delete that I didn't want to bring up again that kept this WIP.

Would it be easier to proceed if we deferred this decision to a config setting?

[HebaruSan]

Should we add cascade deletion to Following.mod_id and Following.user_id?

[HebaruSan]

Would it make sense to try to delete old records that weren't deleted in the past and now have invalid or missing values?

[HebaruSan]

This 2x2 table layout breaks in a narrow window:

We should try to keep related elements together.

[HebaruSan]

Hmm, it doesn't feel right to assume form inputs in an /api/ route. An "API" should be usable by whatever random JSON clients people want to write (e.g. Netkan or Nertea's publishing scripts), not just the front-end.

Instead of checking whether there's a match after the user clicks the Delete confirmation button, could we try this?

• The Delete button in the popup starts out disabled (but Cancel is always enabled)
• An event handler in the username box checks whether its value is correct, and then enables or disables the Delete button based on that

That way the user could only click the button after they type the name. If some admin wants to delete users with an API script independently, the confirmation flow would not be relevant to them anyway.

This may also make it possible to change the popup form's action to /api/user/{{ profile.username }}/delete and delete most of the new script code.

[DasSkelett]

Hmm, it doesn't feel right to assume form inputs in an /api/ route. An "API" should be usable by whatever random JSON clients people want to write (e.g. Netkan or Nertea's publishing scripts), not just the front-end.

This is pretty normal and standard, we do this in a lot of API routes. That's why they are POSTs. You need some way to transmit data to the server.
I'm not aware of any HTTP client that is incapable of including form data in a POST request. Netkan only reads from the API and doesn't write anything, thus it also doesn't use POSTs. But I'm very confident that WebClient could include form data if it needed to.

Here it is primarily meant as a "confirmation" feature so you don't delete your account accidentally. Whether that's useful for APIs is debatable I guess, I'm okay with removing it. I'm pretty sure that just came from adopting the password change mechanism.

[HebaruSan]

Oh right, the api.md documentation does say:

Submit all POSTS with the request body encoded as
multipart/form-data. Your HTTP library
of choice probably handles that for you. All responses are JSON.

... so using a form input is fine. I guess my objection is just to this one specific form input, then.

[HebaruSan]

Added an implementation of this suggestion in #417, with script code enabling/disabling the button.

[HebaruSan]

Should we use HTTP status codes for this function's returns? The change password route does this, specifically with 403.

[HebaruSan]

Rebased and added a fix for mod_followers to fix 500 errors users have been experiencing at deletion:

Mar 19 15:50:52 sd1a gunicorn[17994]: 2023-03-19 15:50:52,142 ERROR SpaceDock:17994 Dependency rule tried to blank-out primary key column ‘mod_followers.mod_id’ on instance ‘<Following at 0x7f8c8fd720d0>’

Looks like the discussion of what to delete has wound down, and this PR's approach will be fine.

[HebaruSan]

Nice work, and we need it.