Extendable configuration

[eapache]

Affects #7

Adds ClientConfig, ProducerConfig and ConsumerConfig structs and use them in the appropriate constructors. This permits good configuration without overwhelming the constructor parameters (since unspecified values default to 0 which we handle sanely). It also lets us add more configuration options in the future without changing the API, which is a good thing.

Note that this changes the default behaviour in a few cases:

• the client will not retry on a LEADER_NOT_AVAILABLE error unless you specify MetadataRetries > 0
• the producer will not wait for extra acknowledgement from the broker unless you specify RequiredAcks != 0 (it always waits for the TCP acknowledgement).

@burke @fw42

CC @tobi

[burke]

This looks like a reasonable change, but I'm hesitant to add extra burden to clients of the API for the simple case of "I want to post a message". Would it make sense to pass them as pointers and intelligently default nil to a default config?

[eapache]

I don't think passing nil is much easier than passing Config{}?

[burke]

sarama.SomethingConfig{}, in calling code. I'm a lazy typist, and it's easier for the simple-case user to not have to know about a configuration type to assert that they're not doing anything that needs configuration.

Also, I left my phone at home today so I'm not getting github push notifications. Sorry for the delays.

[eapache]

Taking http://golang.org/pkg/testing/quick/ as canonical, you win this round :)

[burke]

LGTM.