Name approval process - modeling and UX overhaul

[sei-bstein]

The current name approval process for users and players is currently a little ambiguous both on the player and admin side.

Player-side issues

• If playing a team game, the captain's name is changed to the team name, which prevents them from being correctly identified on the scoreboard
• Approval times may be longer than desirable, as admins aren't proactively notified upon rename request.

Admin-side issues

• No proactive notifications about name change requests
• Unclear workflow for approving renames or forcibly updating a name, which can cause confisuion (e.g. #180)

Technical implications

• Poor optimization of relational model size (all records have a name request field whether they're using it or not)
• Cumbersome poorly-enforced about the use of various name fields (e.g. Name vs ApprovedName

We'll consider revisiting this. Proposed implementation is:

• Migrate all pending name change requests which have not been evaluated by admins to a new TPH entity (say, NameChangeRequest)
  • Depending on the value of auditing these, either purge requests upon admin judgment or soft-delete
• Overwrite all affected Name columns with ApprovedName values
• Drop ApprovedName
• Update app code to consume Name rather than ApprovedName and NameChangeRequest rather than Name
• Support admin name management with browser notifications

[sei-bstein]

We updated how this works in 3.20.1 such that people with the appropriate permission can edit user names on their behalf, which takes away the awkward usability stuff described above. However, the underlying modeling implications above remain. I wouldn't describe this as a high-priority problem - just something that could be better.