Whisk Client Refactor including Platform Agnostic Home Dir location

[pritidesai]

After go client is upgraded to use platform independent library to determine the home directory (see issue # apache/openwhisk-client-go#108), update whisk deploy to adopt those changes.

Also, @mrutkows and I discovered there is a discrepancy in initializing and creating whisk client object in whisk deploy. There are calls in multiple places which overrides the previous calls.

initConfig at https://github.com/apache/incubator-openwhisk-wskdeploy/blob/master/cmd/root.go#L102 reading .wskprops right when whisk deploy is invoked even before reading manifest file.

Again, while deploying openwhisk assets, new whisk config object is created at https://github.com/apache/incubator-openwhisk-wskdeploy/blob/master/cmd/root.go#L223

The same object is initialized while undeployment at https://github.com/apache/incubator-openwhisk-wskdeploy/blob/master/cmd/root.go#L278 and at https://github.com/apache/incubator-openwhisk-wskdeploy/blob/master/cmd/root.go#L335

Validate whether reading .wskprops in initConfig is of any use and document what is it used for. Discard it if not needed.

[mrutkows]

@pritidesai
In regard to the $HOME/~/UserProfile directory … after having slept on the issue, we may need to replicate what CLI has done in wskdeploy… basically I am wrestling with the issue that the go-client (all clients actually) should likely be agnostic of where they are run (OS/platform) … that info should be injected/provided by surrounding tooling (even if it means, for now CLI and wskdeploy must have duplicate/similar code). If indeed the go-client needs to still have some odd way of providing defaults (not injected by tool using it) then it should also use same lib as an import (edited).

With this in mind, both CLI and wskdeploy SHOULD use the same lib., (i.e, the https://github.com/mitchellh/go-homedir) and set default value to include '~' which the lib. will Expand() based upon OS.

I would think that the design should be that any IDE or app using REST directly should instantiate the go-client (or any client) with the values it needs for the target provider in general
that is just good OO design...

IMO, am 99% sure at least wskdeploy should use the same method CLI is using for consistency at least at our “layer” of tooling… and wskdeploy likely should adopt the ENV_ variable as well

[mrutkows]

and of course we need to document the lib. and its MIT license wherever we import (verify in NOTICE file for CLI, wskdeploy and go-client) whenever we implement.