blkfront: c++ify a bit more

This patch make some of the blkfront structures a bit more C++ friendly. I am
creating a C++ version of the device private structure, and the goal here is to
convert it slowly until all or most fields are inside it. At that point, I
expect it to be easy to turn the functions into methods, etc. I am sorry, I
would really like to do a mass translation here, but there are urgent bugs
requiring my attention.

Some notes:
 * I am converting blkfront only, and leaving netfront with the old code. It
   shouldn't be hard, I just deferred the risk of mistakes to a future
   oportunity.
 * you will notice that lines that are added by me are not following the
   original file's identation. This is deliberate. As much as we have in our
   guidelines to preserve the original ident, since we are slowly converting
   those files, our identation should eventually win. Think of it as a form
   of cultural domination. (and shouldn't bother viewers if tabs=4 spaces)

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
blkfront: convert bio lists to C++ lists

They are going to work exactly the same. But with std::list instead

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
blkfront: add the io_mutex to the C++ structure

Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
[ penberg: Fix mixed formatting ]
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
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>