Don't use global state

[ericchiang]

https://github.com/coreos/operator-sdk/blob/01a1d22496f3344e750234bde022f7565d5d0fbe/pkg/k8sclient/client.go#L37-L45

https://peter.bourgon.org/blog/2017/06/09/theory-of-modern-go.html

[mikewied]

This issue blocks #139. I haven't looked into dynamic client pools, but it looks like once you create the client pool the any CRD's registered after the operator starts won't be available to the sdkclient API's.

[ericchiang]

cc @rithujohn191

[CSdread]

@hasbro17 @ericchiang is this PR in the direction you were thinking, i want to verify that it is the right direction and i will complete it and add unit tests.

CSdread#1

[hasbro17]

@CSdread I would hold off on that for now. Your PR is in the right direction but there's more to it than just making it a package level singleton.
The client is also used by the Watch API to create the informers which has it's own global state. So we're currently redesigning the sdk.Watch API into a controller package and the client will have to be part of that so it can be exposed to the handler. I will update this issue with more context on that once we have something more concrete on that front.

[hasbro17]

With #382 and the controller-runtime objects we don't have any implicit pkg level state backing global functions(for the client) anymore.