Because of improper bounds checking, when receiving a structured reply
some offset/lengths sent by the server could cause libnbd to execute
arbitrary code under control of a malicious server.

A structured reply segment containing (for example):

  offset = 18446744073709551615 (== (uint64_t) -1,
                                 or similar negative offsets)
  length = 100 (any small positive number < request count)

In both original bounds tests the error case would not be reached:

  if (offset < cmd->offset) {         // very large < 0
    // error case
  }
  if (offset + length > cmd->count) { // 99 > 512
    // error case
  }

The result of the negative offset is that data under control of the
server is written to memory before the read buffer supplied by the
client.  If the read buffer is located on the stack then this allows
the stack return address from nbd_pread() to be trivially modified,
allowing arbitrary code execution under the control of the server.  If
the buffer is located on the heap then other memory objects before the
buffer can be overwritten, which again would usually lead to arbitrary
code execution.

This commit adds a central function to handle bounds checking for all
cases, and the corrected bounds check is written once in this function.

This bug was found by fuzzing libnbd with American Fuzzy Lop as
described here:
https://groups.google.com/forum/#!topic/afl-users/WZzAnfItxM4