rover subgraph init should create a .apollo configuration directory

[EverlastingBugstopper]

rover should recognize a .apollo directory and allow required arguments to become optional if they are specified in config.

implementation:

we should closely map configuration keys to their associating flags/arguments. config options should be resolved to a single struct (may need to do some refactoring to enable this and also work with environment variables)

[EverlastingBugstopper]

this recent refactor starts laying the ground work for this I think

[EverlastingBugstopper]

docs for rover subgraph init should look something like this:

Initialize your subgraph

Run rover subgraph init to create a new subgraph and answer the questions provided by the wizard. Below is an example of bootstrapping a supergraph with a single subgraph. Debug statements are included to show some of what's happening behind the scenes including what the config file will look like.

$ rover subgraph init --log debug
Are you extending a pre-existing supergraph? (Y/N)? N
DEBUG no supergraph exists, prompt to create one
What is the name of the supergraph you would like to create? my-supergraph
What is the name of the subgraph you would like to create? my-subgraph
What is the endpoint for developing 'my-subgraph' locally? http://localhost:4000/graphql
What is the endpoint 'my-subgraph' will be deployed to? https://my-subgraph.apollo.dev/graphql
Where can the schema for 'my-subgraph' be found?
> * Local filesystem
  * Introspection
  * Apollo Studio
What is the path to the schema for 'my-subgraph'? ./my-subgraph.graphql
Creating .apollo/project.yaml for 'my-subgraph'...
DEBUG ApolloConfigDir {
  ApolloConfigYaml {
    project_type: subgraph
    supergraph: 
      id: my-supergraph
      default_variant: current
    subgraphs:
      my-subgraph:
        schema:
          file: ./my-subgraph.graphql
        variants:
          current:
            routing_url: https://my-subgraph.apollo.dev/graphql
        dev:
          routing_url: http://localhost:4000/graphql
  }  
}
Successfully initialized 'my-supergraph' and 'my-subgraph'. 
    You can run `rover subgraph dev` to test 'my-subgraph' locally, or you can publish 'my-subgraph' to Apollo Studio by running `rover subgraph publish`.

Per-variant configuration

If you pass a --variant to rover subgraph init after already initializing your configuration directory, Rover will automatically insert the new configuration for that variant. This configuration will be used when publishing your subgraph to Apollo Studio.

$ rover subgraph init --variant staging --log debug
Reading contents of .apollo/project.yaml...
DEBUG ApolloConfigDir {
  ApolloConfigYaml {
    project_type: subgraph
    supergraph: 
      id: my-supergraph
      default_variant: current
    subgraphs:
      my-subgraph:
        publish:
          variants:
            current:
              routing_url: https://my-subgraph.apollo.dev/graphql
        dev:
          routing_url: http://localhost:4000/graphql
  }  
}
What is the endpoint 'my-subgraph@staging' will be deployed to? https://staging.my-subgraph.apollo.dev/graphql
Creating 'subgraphs.my-subgraph.publish.variants.staging' in .apollo/project.yaml...
DEBUG ApolloConfigDir {
  ApolloConfigYaml {
    project_type: subgraph
    supergraph: 
      id: my-supergraph
      default_variant: current
    subgraphs:
      my-subgraph:
        schema:
          file: ./my-subgraph.graphql
        publish:
          variants:
            current:
              routing_url: https://my-subgraph.apollo.dev/graphql
            staging:
              routing_url: https://staging.my-subgraph.apollo.dev/graphql
        dev:
          routing_url: http://localhost:4000/graphql
  }  
}
Successfully initialized 'my-subgraph@staging'. 
    You can run `rover subgraph dev --variant staging` to test 'my-subgraph@staging' locally, or you can publish 'my-subgraph@staging' to Apollo Studio by running `rover subgraph publish --variant staging`.

[lrlna]

@EverlastingBugstopper noting down the discussion we had about keys/env vars.

Since users are expected to commit .apollo, it'd be good to think about how we'd like to handle any secrets, especially in CI contexts. While it's likely not pertinent for the current implementation, I think it's good to keep that in mind. If it seems like there is a possibility of .apollo containing secrets, we should make sure to write up a guide for our users as to how they can use env vars or something else to keep their .apollo secure.

[EverlastingBugstopper]

Yes - we should probably support environment variable expansion just like the router config does. Docs for that are here, and it looks like @BrynCooke recently worked on improving its functionality in this PR. It looks like the envmnt crate provides some utilities that we could use here.