Refactor the client (again) to better support auth

Allows consumers to provide their own transports for common cases.

Fixes #1499
Adds basic support for #1473
I considered it (and was halfway on the fence) - two things that have me leaning slightly to the big jumble:

1. Makes it easier to initialize and bind the fields to flags (which was partially the point) - with pointers you'd have to create the nested object anyway to bind it to a flag

2. Makes nested initialization in tests and simple usage shorter.  I'm assuming every client will supply a form of auth eventually, so doing

        client.New(&client.Config{Host: host, Basic: &client.BasicAuth{Username: "bob", Password: "test"}})

   Just didn't seem as clear as

        client.New(&client.Config{Host: host, Username: "bob", Password: "test"})

I also figured that more complicated config can be done piecemeal without calling New, so I was thinking of New as the convenience constructor.

Could be persuaded otherwise if you feel strongly about the other way.

> On Sep 29, 2014, at 11:40 PM, Brendan Burns <notifications@github.com> wrote:
> 
> In pkg/client/helper.go:
> 
> > +package client
> > +
> > +import (
> > +	"fmt"
> > +	"net/http"
> > +	"net/url"
> > +	"path"
> > +	"strings"
> > +
> > +	"github.com/GoogleCloudPlatform/kubernetes/pkg/api/latest"
> > +)
> > +
> > +// Config holds the common attributes that can be passed to a Kubernetes client on
> > +// initialization.
> > +type Config struct {
> > +	// Host must be a host string, a host:port pair, or a URL to the base of the API.
> Hrm, I don't super love all of these fields for different auth smashed together here? Break them up into per-auth type pointers to structs?
> 
> —
> Reply to this email directly or view it on GitHub.