Unify settings and secrets configuration and define a proper workflow

[ferblape]

TBD

• we don't need a secrets.yml.example, we can use secrets.yml with env vars
• how to keep .env.example and .env updated?
• we don't need database.yml.example
• we can use application.yml

[ferblape]

Idea: update the PR template and ask if .env.example or application.yml have been updated.

[danguita]

I agree on adding the config/secrets.yml file to the repo since we are not (or we should not be) storing actual data there but retrieving them from the environment. The same can be applied to the config/database.yml file 👍

Regarding .env, I would say there is not a reason to keep it sync with the example file since we should be able to load the application with a totally customised environment. This includes the absence of some of them as long as we provide default values wherever needed. So, I would say that just pointing out there are new settings and/or environment variables that could be set up should be just enough. I agree doing so at PR level to keep them in context, but I would also make it part of the release process so we can mention it in each version's change log as development notes. What do you think?