Loading secrets from .env in the development environment

[Kavignon]

This PR will resolve #10

Setting environment variables at build-time

We have variables baked into the dev container that aren't secrets at build-time. They are available for anyone to consume and leverage within their development container. Think of the environment configuration that one might need to have something work as they anticipate but doesn't provide any tangible sensitive information away.

ENV MIX_ENV=dev
ENV MIX_HOME=/root/.mix
ENV PATH="$MIX_HOME/escripts:$PATH"

Setting environment variables at run-time

We're specifying to the development container to pull environment variables set on the host's machine and pulling them on the fly for the container to use. For instance, we could think of API key, database credentials or tokens of any kind.

Such as doing something akin to this in the devcontainer.json

"remoteEnv": {
      "GITHUB_TOKEN": "${localEnv:GITHUB_TOKEN}"
}

Values are passed down to the container at runtime instead of build time. The container will only receive these values at the moment it starts. This ensures that they're not written in any of the container's layers and kept out of source control through the .gitignore., making it harder for malicious users to extract secrets from the setup.

This is just for the development environment. We would need a more robust system for the production environment to handle secrets and pull the information from that location.

[Kavignon]

The proof that the prior mix task is too busy:

elixir-kickoff/lib/mix/tasks/post_start.ex

Line 12 in 80b5525

log_step("Loading environment variables", &load_environment_variables/0)

We were already loading the environment variables with a custom script. I prefer to use a dependency focused on that problem instead of doing it by hand.

It is outside the scope of this PR, but I think it's a good idea to break down that big mix task into separate tasks. For instance, we could have different modules focused on various problems and a single post_start task that merely orchestrates the work to be done.

We're close to that, but the file is too busy, to the point that I forgot about an implementation I made a few days ago.