Refactor mix environment files so they are untethered from deployment configurations

[joshsmith]

Problem

Per some advice from @DavidAntaramian:

In essence, your Mix environment is not the same as a Rails environment. Very different beasts. The Mix environment should only control build concerns (like, "Should debug information be stripped from this file?") not runtime concerns. We've been bad as a community in communicating that, though.

So, for example, the URL for the web app used in emails, that should really be stored in an environment variable. You might provide a default in the config.exs file, but then try and load the OS environment variable inside the application's start/2 function and inject it into the application's Erlang environment store (Application.put_env(:code_corps, :allowed_origins, allowed_origins))

Ecto and Phoenix are trying to be better about allowing this type of thing. So Ecto has a callback on Ecto.Repo called init/2 that you can define and use to fetch environment variables defining connection information rather than storing that in the config file (https://hexdocs.pm/ecto/Ecto.Repo.html#c:init/2). Phoenix.Endpoint has a similar init/2 function for defining URL and HTTP transport configuration (https://hexdocs.pm/phoenix/Phoenix.Endpoint.html#c:init/2)

This is going to require:

• cleaning up the config files
• setting the new configuration on the servers, where needed
• documenting the configurations somewhere so they are not solely stored on our servers (or with any specific PaaS)

[zacck-zz]

Hey @joshsmith I'd like to take a try at setting this up

[begedin]

@zacck Parts of this require administrative access to our remote dev, staging and production servers, so I'm not sure what percentage of this you'll be able to do.

[zacck-zz]

@begedin Oh I see that's cool by me