proposal: add `APOLLO_ROUTER_DEV` env var to enable default plugins for development

[EverlastingBugstopper]

context

1. we are shipping the first version of rover dev soon
2. the router configuration file format is not stabilized from version to version
3. rover dev should be able to use any version of the router it wants
4. the current rover dev prototype hard codes the configuration for the router to enable a useful local development story (namely enabling subgraph errors, down the line we will want to configure things like the port it's listening on as well)

problem

if configuration options we set in rover dev for router v0.12.0 are no longer applicable/valid in v0.13.0, or there are improvements to the dev mode in newer versions of the router, old versions of rover dev will be incompatible with the newer router configuration. 😿

solution

the router should provide an APOLLO_ROUTER_DEV_MODE option that sets some of its own default configuration. the actual options that are set can be changed over time, and the router team will be able to make incremental improvements to rover dev without needing to ship new versions of rover. 🚢

this should not be exposed in router documentation or configuration help text, it is purely for stable interactions between the router and rover.

[abernix]

@EverlastingBugstopper Thanks for opening this for discussion!

My hunch is that we're going to need to invest a little bit of time in figuring out the interfaces here because --dev is, I think, just one example of an agreement we need to be durable across the Rover/Router. Also, we've believed that rover dev is the way that we want users to be running the Router and we've intentionally not introduced the --dev flag a couple times now because we've wanted to start a conversation with Rover as to how we could do that (because ./router --dev and rover dev are... I think very intersected).

As a very near term suggestion, could Rover set some environment variable when spawning the Router so we know that is how we've been launched? (e.g., APOLLO_ROVER_DEV=true?). I like the idea of something general purpose, yet durable, that you could commit to in the long-term. Essentially, properties of the environment made generally available to spawned tasks similar to the expectations that cargo or similarly npm make available.

In the very near term (and perhaps short-circuiting the immediate introduction of this flag), the Router could make some decisions based on that environment variable and launch a bigger conversation about whether we want to create a separate "router dev" experience (which ./router ---dev really is) that stands alone.

Thoughts?

[EverlastingBugstopper]

talked w/ @BrynCooke about this this morning - he thinks it's fine to have this if we don't have it in clap help output or in the docs, which i think i agree with.

the main thing here is that we need a stable way to allow rover to set some plugins if we allow multiple versions of the router to be orchestrated by rover. we can get rid of this if we just hard code a version of the router for each rover version.