Proposal: Rover config file | supporting rover environment configs in profiles

[LongLiveCHIEF]

Description

When rover is run from behind a private network, external communication is difficult, and thus various configs must be set from environment variables to make sure any communication rover does is successful. This becomes a challenge in making the rover experience smooth across a development team, because they have to keep remember to run automation scripts to set a bunch of environment variables or source a .env file.

Instead, rover could check to see if there is a .roverrc file either in the cwd, or the root config directory (maybe same dir rover config auth is stored), and would automatically use these settings when run. In this way I could commit .roverrc files with my project, and other teammates would get consistent rover behaviors without having to remember to run automation scripts or source environment variables.

Right now, in order to get rover to work consistently without failing on rover dev or rover supergraph commands, we have to set the following env vars:

export APOLLO_ROVER_DOWNLOAD_HOST="https://${USER}:${TOKEN}@${HOST}/${ROVER_REMOTE_HOST}"
export APOLLO_ELV2_LICENSE="accept"
export APOLLO_ROVER_DEV_ROUTER_VERSION="1.52.0"
export APOLLO_ROVER_DEV_COMPOSITION_VERSION="2.8.2"

We also will typically use flags like --skip-update, which would be great to be able to set in a .roverrc file.

Support in rover config profiles

Another thought is that rover profiles could be expanded upon to support these settings, so that rover config set <config> <value> would work to set configs inside the current profile, (or you could pass --profile) to setorget` specific values into a desired profile...) allowing for easy switching for different environment configurations.

Implementation details

Heirarchical configuration value setting

I think it should work similarly to how git config and npm config work, where it will use a global file, and then also a local file. NPM configs also use environment vars in the heirarchy by auto-loading anything from the environment with the NPM_CONFIG_ prefix.

I imagine the heirarchy could look like this for each value:

1. Default Value
2. Global config file
3. Environment Variable?
4. Rover config profile*(see note)
5. local config file*(see note)
6. command line flag

Configs vs Flags

I think there's a difference between a rover config value and a config value for a graph/contract/etc...` I think it would be good to clarify the support of configs through the heirarchy above is limited to rover configs, and not subcommand configs. (those would still work like they do currently, using various config files and flags)

So for example, setting rover_dev_router_version in a .roverrc or a rover profile would be valid, but setting apollo_graph_ref would not be, since that is a subcommand config.

This could be open to change, especially for configs like --supergraph-port which are unlikely to change.

*Note it's possible that by switching the loading precedence of rover profile with local config file would enable subcommand configs to work in this system as well