The block that the client claims is the current last block
doesn't match up with what we think is the last block. There are
three possibilities:
1) This is the first block allocation of an append() pipeline
which started appending exactly at a block boundary.
In this case, the client isn't passed the previous block,
so it makes the allocateBlock() call with previous=null.
We can distinguish this since the last block of the file
will be exactly a full block.
2) This is a retry from a client that missed the response of a
prior getAdditionalBlock() call, perhaps because of a network
timeout, or because of an HA failover. In that case, we know
by the fact that the client is re-issuing the RPC that it
never began to write to the old block. Hence it is safe to
abandon it and allocate a new one.
3) This is an entirely bogus request/bug -- we should error out
rather than potentially appending a new block with an empty
one in the middle, etc