add whoami command

[JakeDawkins]

Using an API key, we get back the name, id, and kind of api key (or an error with suggestion if invalid).

From a first look, we could also expand this to do other things, like list org memberships of a user key or list the permissions of a graph key! I just figured having a simple "is this api key valid" command as a first pass would be helpful!

This command also works with no profiles at all, using the APOLLO_KEY env var:

[EverlastingBugstopper]

lgtm!

[glasser]

Some thoughts on a confusing part of the Studio API.

[glasser]

I think I would not recommend reading this field and displaying it to the user as "name". This isn't well documented (our schema isn't too documented, sorry) but this interface field has two real implementations: Service.name and User.name.

Service.name is actually a deprecated field: the value in it is referred to as "title" these days in our UI and has a non-deprecated Service.title field. (We thought it was confusing to have the name and ID be distinct things — people generally referred to the the ID as the name. So we changed it so the things are "title" and "ID", and often use name to mean the latter. So Rover shouldn't use name to mean the former.)

User.name is literally just User.id without the first few characters (gh. etc).

I would recommend not querying Identity.name or displaying a Name: line, but instead doing a ... on Service { title } and showing that field as "title" for graphs specifically. See next comment for more on the User case.

[glasser]

While I think it's reasonable to display IDs for debugging, I'll note that we don't actually show the user ID to users on the Studio UI. For first-party users, this is just fp.UUID, and as of recently new GitHub users are also gh.UUID (and for older GitHub users, the ID might not actually match their username if they've changed it on GitHub). So while it's probably reasonable to display the ID, it would be very valuable to also show ... on User { email githubUsername }.