Change update user API to allow for crates.io username changes with some restrictions

[carols10cents]

This issue feels somewhat large; this can be broken up into multiple PRs if desired.

This depends on the PR adding reserved crate names: #13765

This issue is only for the API changes; there is a separate issue for changes to the UI to make use of this new API ability.

In a similar manner as the deleted_crates table, add a deleted_usernames (or abandoned_usernames? because this will be for usernames that someone decided to stop using by changing to something else, not necessarily by deleting their account).

• Add to update_user a field for username in the JSON

• Similarly to the validate_crate_name function, create a validate_username function that:

  • Only allows usernames to contain alphanumeric characters ([a-zA-Z0-9]), hyphens (-), and underscores (_).
  • Doesn't allow usernames to start with a hyphen or underscore.
  • Doesn't allow usernames to exceed 39 characters.
  • Returns explanatory errors if any restrictions are violated.

• Similarly to the check of deleted_crates in crate publishing, verify that:

  • The new username is available to use
  • The current user changing their name has not changed their name in the past 30 days

• Similarly to the check of reserved_crate_names in crate publishing, verify that the new username isn't reserved

[avirshup]

Hi, first time contributor, saw some discussion on mastodon and wanted to help if possible.

I've taken a swing at the first part of this issue - PR #14069 sets up the abandoned_usernames table, trying to follow existing patterns in the rest of the database as much as possible. If this schema looks good, I can follow on with a second PR for the application-level changes.

As suggested in the issue, I made abandoned_usernames pretty similarly to the deleted_crates table. For naming, I used adopted/abandoned instead of created/deleted, since those verbs seem a little more appropriate here?

One question: for the application side of this, I'm not quite sure how it will get the value for the abandoned_usernames.adopted_at field (i.e., the datetime when the user started using the username). Would it make sense to also add an adopted_current_username_at: timestamptz column to the user table? (Alternatively, the adopted_at timestamp isn't strictly necessary for implementing this issue ... although it seems like it the sort of information that would be good to store)

[avirshup]

FYI, I now have this issue fully implemented in #14088.

[carols10cents]

One question: for the application side of this, I'm not quite sure how it will get the value for the abandoned_usernames.adopted_at field (i.e., the datetime when the user started using the username). Would it make sense to also add an adopted_current_username_at: timestamptz column to the user table? (Alternatively, the adopted_at timestamp isn't strictly necessary for implementing this issue ... although it seems like it the sort of information that would be good to store)

Yeah I'm not sure that the adopted_at timestamp is necessary, nor will it be very useful if it's not often available. For example, for all existing users, we don't really know when they started using their current username. We only recently started tracking users.created_at, and for existing users, that was set to the time that PR was deployed.

[avirshup]

Yeah I'm not sure that the adopted_at timestamp is necessary, nor will it be very useful if it's not often available.

Ok thanks, that actually simplifies things quite a bit! I've stripped everything around that timestamp out of #14088 - but it's still marked as a draft due to the uncertainty about when it should be deployed.