Add the ability to use a custom HTTP Client to the push

[shlimp]

Currently, the push to gateway function uses http.DefaultClient to make the request to the pushgateway.
By abling to use a custom client, there can be more flexibility on how requests are sent.
For my specific usage when I encoutered the need, I am using the client from GAE, which doesn't allow at all using the http.DefaultClient, which makes the library unusable in GAE

[beorn7]

Good point.

Question is how to implement this best. The naive approach would be to duplicate each existing function in the push package to also accept an http.Client, i.e. func push.Collectors(job string, grouping map[string]string, url string, collectors ...prometheus.Collector) error would be complemented by func push.CollectorsWithClient(job string, grouping map[string]string, url string, client http.Client, collectors ...prometheus.Collector) error. However, the multiplicity of options calls for either an options approach or a builder approach. Mock-up calls:

Options approach:

// Easy case:
push.Collectors("http://example.org/metrics", "my_job", push.Options{}, myCollector)

// Complex case:
push.Collectors(
    "http://example.org/metrics",
    "my_job", 
    push.Options{
        Add: true,
        Grouping: map[string]string{"zone": "xy"},
        Client: &gae.Client{},
    },
    myCollector1, myCollector2,
)

Builder approach

// Easy case:
push.New("http://example.org/metrics", "my_job").Collector(myCollector).Push()

// Complex case:
push.New("http://example.org/metrics", "my_job").
    Collector(myCollector1).
    Collector(myCollector1).
    Grouping("zone", "xy").
    Client(&gae.Client{}).
    Add()

I like the builder approach as it naturally allows for multiple Collectors, Gatherers, and even Groupings without maps and/or variadic args. And it would allow to distinguish between the normal push and the "add" push by simply two different methods. It would be a completely different interface. We could simply have them both in the push package and then deprecate the old ones.

@shlimp Now your feature request triggered something way bigger.
Anybody else, what are your opinions? Is it worth it to add something like the above (with the long-term intention of deprecating the old use)? In particular @grobie with whom I discussed the current functions quite a bit (and we were both not entirely happy with it but couldn't come up with something better at that time).