Add a test for the blk-mq direct issue corruption

Add a test for the blk-mq direct issue corruption

This is based on a fio job from Jens with the following description:

  This job file does:

  One write/read verify set, using 256M of files, each 1M. The reader
  part runs 16 times, and in two jobs, while the next write/read verify
  set starts. This set is much larger, it's mainly meant to generate
  write based IO with frequent fsyncs. The fsyncs are key, as they do
  not queue on SATA. This means that the other reads (or writes) can
  get a BUSY condition off direct issue, and with lots of other IO
  going, stay around for a longer time before getting re-issued. This
  increases the chances of a merge happening before they are re-issued.

  I cannot reproduce this on bare metal, tried a lot of different
  boxes. What does work reliably for me is a qemu setup, with 1 CPU,
  and limited to 400M of RAM. The drive used for testing should be
  the following:

  -drive file=scsi.raw,media=disk,if=ide

  created with: qemu-img create -f raw scsi.raw 10G

  The machine type used with qemu was -machine q35,accel=kvm

  Once booted, ensure that sda (if that's the drive above) is not using
  an IO scheduler:

  echo none > /sys/block/sda/queue/scheduler

  Then just normally mkfs + mount the device, and run this job file in
  the mount point.

  Thanks to Lukáš Krejčí for describing how he reproduced it, the qemu
  setup above is directly based on his description.

I.e., it only reproduces the bug under certain conditions, but it's
still valuable enough to have a fio verify test.

Signed-off-by: Omar Sandoval <osandov@fb.com>