blkfront: limit the size of the blkfront queue

I have previously seen situations in which we had a lot more requests than we
can handle, leading to an OOM. I've initially thought that this was because
since there are only max_requests (usually 32) requests, new requests would
overwrite the old bio queue, leading to some of the bio_done functions never
being called.

A closer look at the code was enough to show me wrong, since at the end of the
ring consumption, we do iterate over old requests, processing them.

The real problem then, is that we can generate memory a lot faster than we can
process disk IO. To give an idea about order of magnitude, when a spike would
happen in Xen block (the very problem I am tracking), causing processing to be
interrupted by ~1s, 18k requests would accumulate in the queue. Since after
draining the ring we can only requeue 32 new requests, the end result is that
the 18k requests are never really processed. And at the new spike, 18k more
sit, and so on.

The solution is to adopt a strategy similar to virtio. We'll add a condition
variable to the queue and block new requests while we are processing new ones.

With this patch applied, misc-bdev-write.so runs to completion, but
unfortunately still quite slow.

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>