[writeboost Add benchmark to see randread deterioration

In GitExtract test, we can see Writeboost deteriorates reads.
To see how and why Writeboost does so we use fio to conduct a pure
benchmarking.

Signed-off-by: Akira Hayakawa <ruby.wktk@gmail.com>

----

Hi Joe,

This is my local result. I think we need to analyze where is the bottleneck.
It's getting really bad as iosize increases. This means, I suppose, either of these is the problem.

1. The overhead of splitting IO into 4KB fragments makes it worse. If so, we would need to improve DM framework.
2. The original IO is big sequential but the fragments won't be merged in I/O scheduler. Look, the Elapsed time is not changed so much from iosize=16k to iosize=128k. This means splitting overhead is not the bottleneck but the fact they are not merged is. This can be also investigated by looking at average iosize to the backing device.

If the no.2 above is the real problem making them more likely to be merged could be a solution.

```
Elapsed 24.599707297: writeboost iosize=1k
Elapsed 19.685415928: backing ONLY iosize=1k
Elapsed 12.55639049: writeboost iosize=2k
Elapsed 10.124066019: backing ONLY iosize=2k
Elapsed 6.635716818: writeboost iosize=4k
Elapsed 5.37117554: backing ONLY iosize=4k
Elapsed 5.4943035: writeboost iosize=8k
Elapsed 2.912447417: backing ONLY iosize=8k
Elapsed 5.01504859: writeboost iosize=16k
Elapsed 1.760166793: backing ONLY iosize=16k
Elapsed 4.987177991: writeboost iosize=32k
Elapsed 1.281447999: backing ONLY iosize=32k
Elapsed 4.940747274: writeboost iosize=64k
Elapsed 0.94773723: backing ONLY iosize=64k
Elapsed 4.738596562: writeboost iosize=128k
Elapsed 0.789093387: backing ONLY iosize=128k
```