Normalize codebase to accessing configuration through viper

[hydrogen18]

In the code base we commonly declare flags using the pflag package

cmd.Flags().BoolP("follow", "f", false, "Specify if the logs should be streamed. Defaults to false")

We also do stuff like this

viper.BindPFlag(FlagDeploymentIngressExposeLBHosts, cmd.Flags().Lookup(FlagDeploymentIngressExposeLBHosts))

This "binds" a flag into Viper so that the provided value can be picked up.

The problem is we have code that does this cmd.Flags().GetBool("follow"). When the config is accessed this way we can't actually pick up an env. var. if the user configured it that way.

We need to change all the commands to

1. Declare configuration using cmd.Flags().String() (or equivalent)
2. Setup viper with the appropriate prefix & turn on automatic environmental variables
3. Access all configuration via viper (and no other mechanism) so that our code can use the configuration precedence in Viper and users may configure things however they wish.

[boz]

I fucking hate viper, but yeah, okay.

It is so easy to make a package that populates flags from environment variables, it's ridiculous that everyone uses viper.

/rant

[boz]

I believe this is done by now. What do you think @hydrogen18 ?

[hydrogen18]

There are still places where we access the flags directly like this

https://github.com/ovrclk/akash/blob/master/cmd/akash/cmd/genaccounts.go#L80

I think some changes @troian made did some sort of bidirectional binding, which may have mitigated this but I haven't been through all of what he did in his workaround yet.