Add test for processing large bson entries

Tried this without our modifications and it failed. With our
modifications the test passes.
Merge pull request #12 from Clever/test-allow-large-scans

Add test for processing large bson entries
Support batching oplog replay requests

Before this change when replaying the oplog we maxed out at ~150
requests per second. We think the bottleneck was the round trip time
between the database and the oplog-replay script. To address that issue
we're supporting batching oplog requests.

Conceptually we still have one goroutine responsible for putting the ops
in the "queue" to be processed, but now the goroutine that actual calls
mongo to apply to operation gets all the ops it has in its queue and
applies them at once.
Tweak for golint and comments
Merge pull request #7 from Clever/batch-oplog-requests

Batch oplog requests
Support fixed rate oplog replaying (ops per second)

This change adds an interface for controlling the rate at which we apply
op logs. Theoretically this interface could control the rate at which
more generic things are done. Though it's similar to the leakybucket
abstraction we already have, the relative rate ideas we have didn't
cleanly map onto the leakybucket so I thought this new interface was
useful. I considered doing the interface slightly differently -
returning a time to wait until applying the operation instead of just a
boolean. I ended up going with this because it a slightly simpler
interface, but I could probably be convinced the other one is better.

This change also adds to implementations of the interface. The fixed and
relative rate controllers we want for oplogs. It also adds a new command
line parameter to control which rate controller we use in the replay. It
defaults to the fixed rate.
Change the interface

We want to use the WaitTime() (time.Duration) interface because it's a
bit cleaner.