[Qemu-block] null-co undefined read behavior

[John Snow]

I noticed while debugging an unrelated test that our use of the null
driver has a habit of making functions like find_image_format trigger a
lot of uninitialized memory errors in valgrind, because it will return a
successful read without actually touching the buffer.

I see that in March there was a bit of a debate over whether or not the
null driver SHOULD zero-write memory for performance reasons, but when
this option isn't specified, the semantics of read are arguably broken.

This isn't terribly important to fix, but for actual debugging purposes
it's nice to not have valgrind screaming at you with spurious junk. A
few options:

(1) Admit that it's weird to allow reads to succeed with null-co driver.
Annoy people who apparently wanted performance for their do-nothing
driver and force the initialization of memory.

--or--

(1a) Use valgrind macros to pretend the memory has been initialized.

(2) Band-aid find_image_format to zero-initialize memory. Wonder if
there are other usages of read() getting called from tests that utilize
null-co that will make debugging difficult in other contexts.

(3) Edit any tests to always use the zero option when using the null
driver, and then periodically keep updating this option in a losing
battle over time.

(4) Find a way to adjust return value of null-co's read implementation
to return 0 instead of a lie over the number of bytes it read/wrote.
Correctly represents "No bytes written, but no error occurred either."

(5) Shut up, John, really, who cares? Please shut up. You are the only
idiot who would even think to use valgrind ever, and we just don't like
you that much.

All are kind of bad options, but I like (5) the least.

--js