Don't use global state

[operator-framework]

Don't use global state

[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.