Consider reverting prometheus/client_golang dependency to v0.9.x instead of v1.0.0

[munnerz]

In df0f06f#diff-37aff102a57d3d7b797f152915a6dc16R15, the dependency on client_golang was bumped to v1.0.0.

This was not required as part of bumping dependencies for Kubernetes 1.15.x (as k8s is currently incompatible with v1.0.0 due to the github.com/prometheus/client_golang/prometheus.InstrumentHandler method being removed).

Bumping this dependency in k/k is non-trivial as a replacement for this method is not provided: https://github.com/prometheus/client_golang/blob/2641b987480bca71fb39738eb8c8b0d577cb1d76/prometheus/http.go#L112-L133

controller-runtime does not itself depend on k8s.io/component-base, which is the area of Kubernetes that depends on the prometheus client. Therefore this repository is able to build fine. If another project does depend on controller-runtime as well as component-base (which is a reasonable thing to do 😄), when running go mod tidy the go tool replaces my own require directive to point to client_golang 1.0.0, thus breaking my build of component-base 🙈

Can we revert the dependency version in this repository to alleviate this? I understand it'd be ideal to 'roll forward' in k/k, but this will take a fairly large amount of work and will mean only users depending on bleeding edge k8s.io/* repos will be able to take advantage for quite a while yet.

/cc @DirectXMan12

[gdoctor]

As of now, the earliest github.com/prometheus/client_golang v1.0.0 is supported by core kubernetes (https://github.com/kubernetes/kubernetes/blob/v1.17.0-beta.0/go.mod) (and component-base https://github.com/kubernetes/kubernetes/blob/v1.17.0-beta.0/staging/src/k8s.io/component-base/go.mod) Makes a lot of sense to me to revert for compatibility reasons.

[DirectXMan12]

yeah, this seems reasonable. Please file a PR. We'll un-revert when 1.17 comes out.