Clarify partition surrender logic

[mcandre]

The README describes some kind of automatic load balancing of partitions to consumers via groups, wherein partitions are "surrendered" when Marshal notices that the consumer read counter falls too far behind the topic write counter. Does this surrendering always happen, or just when there are other connected consumers in the same group available to receive the surrendered partition?

Just double checking that a partition would not be surrendered in the case that there is only one connected consumer in a group, which would cause the offset to fall even further behind heh

[zorkian]

There's an option you can toggle if you want it to release if behind or not:

	// ReleaseClaimsIfBehind indicates whether to release a claim if a consumer
	// is consuming at a rate slower than the partition is being produced to.
	ReleaseClaimsIfBehind bool

If the option is on it always releases. If it's off, it never releases. There should really be a third state that is 'release if behind and there are people available to pick it up', but that hasn't been implemented yet.

At Dropbox we prefer to release because we only retain data for 1-5 days (depending on topic) in our clusters and we want to hard-stop processing (which guarantees alerts fire here) than slowly get further behind until you fall off the wrong end and data expires out from under you. The partition release mechanism also gets picked up in our alerting system which fires consumer group coverage alerts, basically, so people know they're not consuming everything.