Fix Racy call to Reset in feederLoop

[nemosupremo]

Checking Reset()'s active return value is racy according to Golang docs.

Note that it is not possible to use Reset's return value correctly, as there is a race condition between draining the channel and the new timer expiring. Reset should always be used in concert with Stop, as described above. The return value exists to preserve compatibility with existing programs.

Docs advice to call Stop in order to reuse a timer. Should fix #732.

[eapache]

Thanks! Stuff like this makes me wish Go had some sort of deprecation flag so the compiler would have warned when using the return value of Reset.

[nemosupremo]

I believe this patch is problematic as well - this is now happening to me in prod:

goroutine 273 [chan receive, 10 minutes]:
github.com/Shopify/sarama.(*partitionConsumer).responseFeeder(0xc820bb3880)
    /go/src/github.com/Shopify/sarama/consumer.go:425 +0x1da
github.com/Shopify/sarama.(*partitionConsumer).(github.com/Shopify/sarama.responseFeeder)-fm()
    /go/src/github.com/Shopify/sarama/consumer.go:158 +0x20
github.com/Shopify/sarama.withRecover(0xc820c4c060)
    /go/src/github.com/Shopify/sarama/utils.go:46 +0x3a
created by github.com/Shopify/sarama.(*consumer).ConsumePartition
    /go/src/github.com/Shopify/sarama/consumer.go:158 +0x4a8