design question: consume = lose, or ack on consume?

[Dieterbe]

in nsqd/diskqueue.go , any data consumed from the diskqueue is considered dealth with, the reader is moved, the data becomes programmatically inaccessible and gets garbage collected from disk when we move to the next file.

if data read from diskqueue could not be properly processed, it's up to the user of diskqueue to handle this, often just requeueing the same data to the head of the queue.

While this works for nsqd, I think maybe the behavior for this WAL project should be different. Basically use ack's so that readers can confirm when they want to move to the next position.
this should be more gentle on the hard drive, perform better, and don't introduce needless reordering, (which seems useful for a bunch of applications, even with no ordering guarantees, consumers that have to re-order data in a window will have to do less work)

[mreiferson]

This isn't implemented yet but the design includes "retention windows" that can be defined in bytes.