Puller revoked docs should queue with other revs

Pull uses a counter, _activeIncomingRevs, to count the number of active workers that are handling incoming revs concurrently. The current cap is 100. When more messages arrive, we put them in a queue, where they will be processed when _activeIncomingRevs drops below the limit (100).

There is a case where the _activeIncomingRevs grows thousands, (40,000+) and the document updates are not being handled properly. The reason is that there is a lots of purge revs, and any purge revs do not wait in the queue behind other revs, instead they are handled instantly, but they still increase _activeIncomingRevs count, so other (non-purge) revs are waiting for the count to drop below 100.

This could be by design, so access revocation is instant? (Update: it's not) If not, purge revs should wait in the queue with other revs