Improve configuration process

[ivanzy]

This PR implements 4 features mentioned in the issue #25 . Namely:

• Refactoring code to have a structured config model
• Support different development environments: the NODE_ENV variable defines which .env file should be loaded from the envs directory.
• Hooks on package.json: the prefix NODE_ENV=environment was added in the run:dev and run:prod
• Review and check the defaults: A class was created that holds the default values of al configs utilized in Zion.

[hyperloris]

Thank you for your contribution!
There are two minor issues that need to be addressed before merging the PR:

1. In src/config/interfaces you are using a lowerCamelCase convention for file names. In this repository we are adopting the same convention used by NestJS. You can read more in the CONTRIBUTING document.
2. The env files are inside src/config/env. I suggest moving them to the root of the repository. To be more precise, I would move the .env file to the root level and test.env inside the test folder so that the "testing block" is treated as a separate application.

[ivanzy]

I do not agree on the second point. The idea is that the env variables should not be scatter over different directories. I know that if we have only a template .env and a test.env this would not be a problem, but we envision multiple possible enviroments, such as production, staging and more. Then, Where should we place the .env?

The use of a envs directory is not so rare in NodeJS systems, they do it in those tutorials: https://blog.devgenius.io/environment-variables-in-nest-js-b989bb0370bf and https://dev.to/pitops/managing-multiple-environments-in-nestjs-71l

[relu91]

I do not agree on the second point. The idea is that the env variables should not be scatter over different directories. I know that if we have only a template .env and a test.env this would not be a problem, but we envision multiple possible enviroments, such as production, staging and more. Then, Where should we place the .env?

I'm on call right now, and I might extend this answer later but I would simply say: in the root folder. The test.env is just a special case for our integration test. It is not a real testing environment (like it might be a server where we do a couple of benchmarks or other validations). If that still bothers you (tbh I don't like exceptions either) I would propose the following:

• both env files in the root folder
• both env files inside a /config folder

[relu91]

Can you rename config interfaces from <name>.ts to <name>.config.ts, I think config word in this case specifies the scope of the file content.

[ivanzy]

I addressed both the requested changes in the last commits:

• config interfaces were renamed to *.config.ts
• .envs files are in the root