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
four possibilities:
1) This is the first block allocation of an append() pipeline
which started appending exactly at or exceeding the 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
to return the existing block.
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
4) This is a retry from a client that timed out while
the prior getAdditionalBlock() is still being processed,
currently working on chooseTarget().
There are no means to distinguish between the first and
the second attempts in Part I, because the first one hasn't
changed the namesystem state yet.
We run this analysis again in Part II where case 4 is impossible.