block: add support for barriers

[g2p]

This is to allow mandating ordering constraints on writes to block devices.

Some block devices behave sequentially by default, others don't.
A barrier mandates that write calls done before the barrier will land before any write calls done after the barrier call.
That is to say, even after an unclean shutdown, data that was written after the barrier will either fail to have persisted or will be able to reference the entirety of the data that was written before the barrier.

A durable barrier adds the guarantee that write calls done before the barrier will be as durable as the device can make them (this may involve cache flushing) once the barrier call has returned.
That is to say, after an unclean shutdown, data that was written after the barrier will either have persisted or the device will report errors.

Here's how the signature of the Mirage interface would look like:

  val barrier: ?durable:bool -> t -> (unit, write_error) result io
  (** [barrier device] will make sure that all writes done prior to the barrier
      call will hit [device] before the writes that are done after the barrier
      io has completed.
      No guarantee is made for writes made during the barrier io.
      If ~durable:true is passed, all writes prior to the barrier
      will be as durable as the device can make them, which may be slower.
      If ~durable is false or omitted, the implementation may still
      rely on slower, durable primitives if these are the only ones
      available. *)

[mato]

Yes. You probably want to look at #325 first though.

[g2p]

It looks like it can only be implemented on spt ant hvt (with fdatasync, so more costly than a basic barrier).
Virtio has support too (as an optional feature), but I don't know of a backing implementation that implements it.