Tuned wait time of function receivedGetMore() when spinning waiting for data on capped collection

When using MongoDB in a producer/consumer pattern, there's a minimum response time that can't be overcomed, which is 2ms.
It's very likely than a Consumer inserting a request on a capped collection will initiate waiting as soon as finish inserting, and it's also likely that the producer won't be able to produce a response faster than the first attempt to read from the collection while tailing, therefore falling into a 2ms wait on the consumer side.
This tuning will loop for 400 times first using Sleep(0) to yield CPU, before using 1ms wait and then finally 2ms wait.
We will sacrifice a little bit more CPU than previous implementation for the sake of better response times on capped collections.

Ideally this whole code could be refactored using events, where the consumers waiting on a tailing cursor could subscribe to an event linked to the underlying collection object, and when insertion happens on the collection the event is set to signaled state implementing no-spinning waits in this way. There will be immediate response time with no CPU sacrifice at a cost of slightly higher complexity. If all paths to insertions are consolidated on Collection class, the complexity should be relatively low.