Use viper bindings for all env vars

[shaggyone]

Made all options, previously passed through Env vars configurable.

Motivation: Env vars with secrets will most likely be stored in some script, or whole command some potentially unsafe location. The solution provided allows using simple terraform-backend-git git terraform ... command without need to add extra params.

Two config files: terraform-backend-git.hcl and terraform-backend-git.secret.hcl are loaded by default and multiple --config options are allowed.
README.md recommends adding terraform-backend-git.secret.hcl to .gitignore

[dee-kryvenko]

@shaggyone, thank you for your contribution!

Initially, I intentionally excluded sensitive configuration from cobra and viper. Secrets, generally, should not be laying around on the disk unencrypted - even if they are Git ignored. CLI arguments may be stored in plain text as part of the Shell history. Environment variables, albeit, might also be misused by the users if they decide to put it in a shell script in plain text - but at least it requires explicit extra effort. Secrets should be managed using appropriate secrets management systems such as Kubernetes Secrets, from where it can safely be injected into the execution environment in a form of environment variables. Of course, Kubernetes Secrets may also be injected into execution environment in a form of projected volumes, so I am not trying to say that your use case is invalid - only that it probably may be misunderstood by inexperienced users.

My stance on this issue, however, have changed over time and I no longer believe that any software, but especially - OSS, should impose any limits on users for their own safety. So, I am totally willing to merge your PR, but may I ask you to incorporate this note on the proper secrets management somewhere in the README.md if that wouldn't be too much trouble? If not - that's ok, I can merge it and take care of it in a separate PR.

[shaggyone]

@dee-kryvenko I'm actually open for discussion for a suitable solution. We could use sops for the backend secrets. Or we could add donenv file support, and a final tool user could put something like:

.......
TF_BACKEND_HTTP_ENCRYPTION_PASSPHRASE="$(pass foo/bar/TF_BACKEND_HTTP_ENCRYPTION_PASSPHRASE)"
.......

[dee-kryvenko]

I don't think secrets management is really in the scope of this backend implementation - I just though some reference to a proper secrets management should be included in documentation.