Issue 326 sanitize logs go

[andrei-panov]

What this PR does / why we need it:
replace bash call with kubectl

Which issue(s) this PR fixes:
Fixes #326

Special notes for your reviewer:
It should be possible to follow commits to make the review. I left some methods and tests which will be deleted after review.
At the moment I can't test if it's really getting the logs because I'm missing some permission.

Release note:

[andrei-panov]

Here I want to put some arguments about why another package is for good (subcmd/kubectl)

1. It reduces the scope.
   Once we agreed to have all the functionality in this package than when you open the kubectl.go file you will be confident that you working only with this limited scope. You even allowed to introduce private methods not accessible outside the package. We have some private methods currently but it doesn't work since it's the same package everywhere.
2. reduce spaghetti code
   As an example: KUBECONFIG variable setted up and readed from many different places. If you decide to collect all the logs from different places (garden, seed, shoot) in parallel, it becomes impossible because it's out of control when the variable will be updated. Get one by one is the only option for now.
3. smaller package is more testable
   Smaller package scope gives you more confidence during refactoring.
4. extension functions
   It's not directly related to a separate package, but once we move all the functionality related to kubectl to a dedicated package we can refactor the functions to extension functions over some structure. It will reduce the number of arguments which we pass here and there... Same way like go-client does.
   As an example, we can have KUBECONFIG structure and then call config.getLogs() or config.getNS() and execute it against different kubeconfigs in parallel. It might be treated as syntax sugar but it's present in go-land so there no reason not to use it.

I believe that more or less the same arguments might be applied to all other subcommands which we call.
So please treat it as a proposal in general.

PS:

Running Suite: Kubectl Suite
============================
Ran 2 of 2 Specs in 0.000 seconds
SUCCESS! -- 2 Passed | 0 Failed | 0 Pending | 0 Skipped
PASS
coverage: 100.0% of statements

you see... 100% for the whole suite :) It's not the goal... but who knows... what will convince you :)

[dansible]

Hi @andrei-panov, I totally agree regarding reducing the scope of changes and making it easier to test and extend features. The issue is that these changes are outside of the scope of this PR/issue, which is for sanitizing the inputs to the logs subcommand. The repackaging work is a big refactor that should be tracked in its own issue and handled with smaller PRs that focus on one subcommand at a time. If this is something that you'd like to work on, I would encourage you to open an issue to track this either just for the kubectl subcommand or a larger umbrella issue that describes the proposed outcome for all packages.

Regarding the logs all target, the PR for that is here: #437

[andrei-panov]

@dansible Please review it