That has a `provider` column that will (for now) always be set to 0,which corresponds to `AccountProvider::Github`.The table's primary key is (provider, account_id), which corresponds to(0, gh_id). This constraint will mean a particular GitHub/GitLab/etcaccount, identified from the provider by an ID, may only be associatedwith one crates.io user record, but a crates.io user record could(eventually) have *both* a GitHub *and* a GitLab account associated withit (or two GitHub accounts, even!)This is the first step of many to eventually allow for crates.ioaccounts linked to other OAuth providers in addition/instead of GitHub.No code aside from one test is reading from the linked accounts table atthis time.No backfill has been done yet.No handling of creating/associating multiple OAuth accounts with onecrates.io account has been done yet.

Right now, this will always have the same value as gh_login on the userstable and login on the linked accounts table. All of these values willget updated when we get a new gh_login value.Eventually, we're going to have to decouple the concept of crates.io"username" from the logins of the various account(s), which you may ormay not want to update when you update your GitHub or other login, andwhich may or may not conflict with other users' crates.io usernames.But for now, set up for that future and defer the harder decisions untillater by making this field always get the same value as gh_login.This adds a `username` field to the JSON views returned from the API butdoes not use that field anywhere yet.Question: should team owner JSON also have a field named `username` asdone in this commit? it's a little weird for a team to have a usernamebecause it's not a user. but it's consistent. something more genericlike `name` might also be confusing. something more specific like`crates_io_identifier` is more verbose but less confusable. shrug