TECH TASK: paramaterize env file for boost, ansible

Value

• the current organization of our .env file has two problems:
  • (1) it groups credentials that are needed both for dev work and for deploying the "official" team-friendo instance to prod. this makes it impossible to give community members access to our dev credentials without also giving them access to prod credentials
  • (2) the boost cli tool defaults to reading $SIGNALBOOST_HOST_URL and $SIGNALBOOST_API_TOKEN from the (TF-prod) .env values, which you must override with a url argument to the -u flag. this:
    • (a) makes it easy for a TF dev to mistakenly create or destroy resources on prod
    • (b) makes it cumbersome for any dev who wants to work on more than one remote environment at the same time. since TF-prod credential values are version-controlled and unlocked with most deploy calls, and since boost currently must read any and all credentials from .env, the mainline deploy process will tend to blast away values for .env causing you to do unnecessary backup copying to defend against this, or to create multiple clone copies of the repo in order to have a copy of .env that is safe from getting clobbered
• if we simply paramaterized .env as an argument to boost, this would solve all of the above problems!

Implementation

• introduce a -e flag to all boost commands that expects a path to the environment variable file it should use for the current invocation
• eliminate the -u flag and instead, always read the target URL for any given boost invocation from the .env file specified by -e
• split the team-friendo credentials into .env (maybe .env.prod?) and .env.dev
• if no value is provided to -e, default to using .env.dev
• since .env.dev will be encrypted for community (non-TF) members, provide an error message that errs toward telling them they need to populate .env (rather than telling them they need to unlock .env.dev)

OPTIONAL ADDITIONAL IDEA:

• allow dev to set a $SIGNALBOOST_ENV_FILE env var. if nothing provided to -e, first check $SIGNALBOOST_ENV_FILE. if it is empty, then default to reading .env.dev
• this will allow users who want to default to always hitting prod to do so, while allowing people who don't know about the env var to continue defaulting to dev