Allow commands to be run in "sudo" mode

[zionts]

Description

Currently, internal Apollo employees (e.g. support staff, sales, engineers), can access users' accounts by activating "sudo mode" on API keys with express permissions. This is done by passing apollo-sudo: true as a header pair to the GraphQL API. This request is to allow sudo mode to be enabled on any command by passing an environment variable APOLLO_SUDO=true or a hidden flag --sudo. This option should not be documented for external use, as only Apollo employees have this sudo-user privilege.

This tool will be valuable for engineers in debugging problems that users run into without having to impersonate that user with their API key.

[lrlna]

@zionts is it essentially that any of the supergraph/graph/subgraph commands can be run with sudo? If that's indeed the case, we may also consider adding a --header flag to all of our commands. graph introspect and subgraph introspect already support headers, so it's not difficult to extend that functionality to other commands.

[abernix]

@lrlna Just to clarify — because I'm not certain it's crisply captured above — this is not about sending a apollo-sudo: true header to customer-owned infrastructure/servers. Rather, on commands that make API calls to our Apollo backend (GraphQL) API, sending the appropriate, special-case header that our backend understands. Put another way, the apollo-sudo: true flag would not be used in an introspect call because it doesn't make any calls to our API. (I don't think?)

(Tangentially, I think we have tried to keep those --header commands isolated to those commands that do make HTTP requests to customer infrastructure rather than having --header support — and connectivity to customer infra — on commands other than * introspect commands. If we do think that would help, we could certainly consider that, though maybe this is a profile setting? My fear is that introducing --header for this purpose might be blurring the lines between "headers for customer infrastructure" and "a special-case header for use when talking to our registry")

[zionts]

I just ran into this again this week when trying to help out a customer and also when trying to make changes to acephei for demo reasons. I can work around this by "stealing" a key, but I do think it'd be nice for the changelog to have the correct actor in the history when support intervenes.