This amazing race condition is the best commit msg you'll read today

So MongoTools has a pubsub.Channel class that we've been using a lot.
It uses a capped collection in combination with a mongotools.Sequence
object to generate an event stream. Unfortunately, this combination
creates a race condition:

1. Thread 1 gets event id 1 from sequence
2. Thread 2 gets event id 2 from sequence
3. Thread 2 inserts event into capped collection
4. Thread 1 inserts event into capped collection

We end up with a capped collection with events:

- `{ts: 2, k: stuff...}`
- `{ts: 1, k: other stuff...}`

Since the query we use is of the form `{ts: {$gt: last_ts_seen}}`
it might seem that this is OK. Unfortunately, we also hint
the cursor to make is tail the oplog properly with
`cursor.hint([('$natural', 1)])`. Which means we can have a situation
where we have timestamps coming out of order, and (somewhat minor,
but still irritating) chaos ensues.

The fix? Quit trying to use an arbitrary capped collection this way.
MongoDB provides a perfectly good event stream with monotonically
increasing timestamps in a capped collection: the oplog.

The fix is this, to keep disruption to a minimum: we keep the
event stream capped collection, but stop generating `ts` values for
it. Instead, we rely on the inserts into the event stream also
being present in the oplog, and we query the oplog instead.

A happy side-benefit of this is that we no longer need the atomic
sequence, which eliminates a findAndModify command for every publish
event, so we should be 2x+ faster on publishing. Yay.