remove borken tests
Check more errors

Caught by errcheck. All remaining errcheck warnings have been audited and are
harmless (mostly because Broker.Open returns such a limited set of errors).
prod: minor simplification

Exactly logically equivalent, no functional change.
Merge pull request #181 from Shopify/more-errcheck

Check more errors
Merge pull request #183 from Shopify/simplify

prod: minor simplification
prod: drain successes on close just like errors

We kindly drain the errors channel on close so that users who stop reading from
it when calling close (e.g. in a defer) don't hang. We should do the same thing
for the successes channel when AckSuccesses is defined.

May or may not fix the bug reported tangentially at the bottom of
https://github.com/Shopify/sarama/issues/180#issuecomment-63127314
where shutting down with AckSuccesses could be very slow.
Launch those two goroutines withRecover
prod: explicitly log every state change

I worked out the formal state machines of the relevant goroutines and stuck a
log message in at every state change. This should help with debugging #179.

The logs should still only trigger on broker rebalance or super-heavy traffic,
so normal operation should be quiet.
Merge pull request #184 from Shopify/prod-logging

prod: explicitly log every state change
Make withRecover raceless for real

Properly fixes #52 this time.

Almost exactly a year ago (+ 3 days) when Flo added the withRecover function we
discussed how if the user set/unset the PanicHandler in time with an actual
panic they could cause secondary panics and weirdness. We decided putting a
mutex in was overkill and closed the issue.

It just occured to me that there is a 1000x better fix, which is to just cache
the handler value locally so we know we're calling the same value we do our
nil-check on. Duh. I'm not sure why neither of us thought of this at the time...
Merge pull request #186 from Shopify/safer-with-recover

Make withRecover raceless for real
client: close backgroundMetadataUpdater faster

Rather than waiting for the next timer cycle (defaults to ten minutes) have it
read from two channels in a select so it tears down right away. It was polluting
test backtraces (where we create and destroy a lot of clients) and making
debugging more difficult than it needed to be.
Fix test raciness

Running the tests with -race indicated a race condition in the mockbroker around
reading/writing b.expecting. Get rid of that value entirely and just use the len
of the channel, which is simpler and less racy.

With that fixed, also fix the hang revealed in TestProducerFailureRetry due to a
mis-ordering and deferal of Close calls. We'd been getting away with it only
because of the race in the mockbroker.

Once this is merged we can do another PR to have CI run with -race.
Merge pull request #188 from Shopify/close-background-faster

client: close backgroundMetadataUpdater faster
Merge pull request #189 from Shopify/fix-mockbroker-race

Fix test raciness
Add a mutex to SimpleProducer.SendMessage

The dumbest (and least performant) way to make SimpleProducer concurrency-safe.
The quick fix for the most concerning part of #187, since the proper concurrency
fix won't have any effect until we can do multiple requests in flight again
anyways.
Remove a dead import from the snappy code
Merge pull request #191 from Shopify/remove-useless-import

Remove a dead import from the snappy code
Merge pull request #192 from Shopify/lock-simple-producer

Add a mutex to SimpleProducer.SendMessage
Remove now-unused error type