[robsimmons]

This PR does two things:

• Adds isAvailableUsername, which allows us to reject already-existing or disallowed usernames. (This doesn't handle race conditions so we're still relying somewhat on the database-level constraint to avoid collision with existing usernames.)
• Adds a retry mechanism findSuitableAlphaNumName that tries to find an acceptable name given a function that rejects unacceptable names. When there's a collision, removes any existing numeric postfix and tries to add postfixes starting with 1.

Closes #132.

[Vtec234]

I think this approach is quite weird. Normally when I attempt to register somewhere with an unavailable, or otherwise malformed, username, something in the UI tells me "this username is taken/forbidden/whatever, please provide another" and often also "here are some suggestions". Here, we approve the registration but just silently modify the username at the backend database layer?

[jcreedcmu]

I had this reaction at first, too, and I'm still a little on the fence, to be honest.

My reason for changing my mind is that normally when I register somewhere, I'm always choosing the username, so it's pretty low friction to be told "that one doesn't work, pick another". Since we are currently automatically taking github id as workbench id, that makes things feel a bit different, but if you want to make the argument that providing an explicit interface for the user to make a choice in the (I expect quite marginal and rare!) case where there's a collsision, maybe we should go that way after all...

[robsimmons]

In all cases where the user is picking a name I definitely want to use the isAvailableUsername function directly to eliminate registered/disallowed usernames. The findSuitableAlphaNumName logic, while admittedly hairy, is intended to eliminate first-login friction: log in with github, you should have a username that is either your github username or something plausibly derived from the same without any additional interaction.