MongoDB driver should support capped collections and tailable cursors

[jmikola]

See #133 (comment) for context.

Using a tailable cursor on a capped queue collection would allow the driver to avoid the poll loop currently done in popMessage() (as implemented in #133). Quoting my original comments:

Ideally, I'd want to use a tailable cursor to block on results with MongoDB (instead of slamming the server with findAndModify commands), but that would require making the collection capped and also complicate the method quite a bit:

• Attempt a findAndModify. If something was found, return it; otherwise, continue.
• Create a tailable cursor to find a message and block up to $interval seconds on it. If nothing is > found, return; otherwise, continue.
• Re-try a findAndModify command, since we expect there is a message waiting. Regardless of whether we find it or not, return afterwards.

and:

Tailing would require that we always have a capped collection. I suppose we could check once when the driver is constructed and assume the collection will be the same for the duration of our execution. This is reasonable, as users shouldn't be dropping and recreating their messages collection while a system is running.

Some caveats of capped collections (from here):

• We can't grow documents. This should be fine because our updates merely flip the visible field.
• We can't delete objects. This means we'd either rely on visible as the deleted flag or introduce a new field to track deleted messages. Since the driver has no way to set visible from false to true, I think using visible to track deleted status is fine. This does mean that acknowledgeMessage() would be a no-op if we're dealing with a capped collection. I think we can still delete messages from non-capped collections, as we wouldn't want those to grow indefinitely.

[jmikola]

@henrikbjorn: Feel free to assign this to me.

[stof]

@jmikola issues can only be assigned to repository collaborators

[henrikbjorn]

Ill gladly just add people, have no issue with that :)