TESTS: Old and new testsuite tested slightly different things for 0block tests

Change all tests in the old testsuite to check 0block tests 2 blocks past the end of the device, just like the new testsuite.

These tests check that we get an error if we do a 0-block read/write etc beyond the end of the device.

In the SBC standard, the only thing that discusses LBA_OUT_OF_RANGE is wordings
such as this :
	If the LBA plus the transfer length exceeds the capacity of the medium,
	then the device server shall terminate the command with CHECK CONDITION
	status with the sense key set to ILLEGAL REQUEST and the additional
	sense code set to LOGICAL BLOCK ADDRESS OUT OF RANGE.

This is very clear for when transfer length is > 0,  but what when
transfer length is == 0?

Assume we have a device that is 0x31fff in size.
With this wording, if we read 1 block at LBA : 0x31fff  we end up at 0x32000
and this is at the end, but not beyond the end.
We are reading/accessing the last block at 0x31fff and we stop at 0x32000.

Similarly, if we are reading 1 block, starting at 0x32000 and reading to 0x32001 which would be LBA_OUT_OF_RANGE since we are accessing beyond the end of the device.

The question now is what happens if we try to read 0-blocks  just at the edge at the end of the device.
I.e. What is we try to read 0 blocks at LBA:0x32000 ?

Looking at the standard, the wordings say that this should be fine.
Because the SBC standard only says that we should check LBA+transfer length.
Thus since 0x31fff + 1 block   is exactly the same as 0x32000 + 0 blocks
thus a device SHOULD allow reading of 0 blocks just at the end.

This is the conclusion from reading SBC by the letter. However It might be unreasonable to do so and it might be wiser to just stay away from this ambigous area of SBC.

Following the SBC standard by the letter,   the new test suite was wrong since it should have flagged this as a failure. But it did checks on one block beyond the blobk at the end of the device.  It checked that we would fail  for 0x32001 in the example above.

Strictly, I should have fixed the new test to check 0x32000   but I think it might be unreasonably to enforce something here for this ambigous area of "what happens when accessing 0 blocks just at the edge of the device".

So instead I have changed the OLD tests so that they now check one block further on. In the example above it means they too now check 0x32001  instead of 0x32000.
Technically speaking this is wrong,  but this is the imho reasonable thing to do.
We should still be able to login even if the device is reserved.

TESTUNITREADY returning reservation conflict is no reason to fail the login
TESTS: Add RESERVE6/RELEASE6 tests
TESTS: Add tests to verify a RESERVE6 is dropped on logout and it-nexus loss
Reservation type not needed to register.
fix reregister to check for resvn conflict

According to SPC, an attempt to register on
a registeried I_T Nexus with the incorrect
reservation key should produce a reservation
conflict.
TESTS: in RESERVE6 test, allow slow targets 3 seconds to notice the nexus loss and drop the reservation
TESTS: Update the "invalid read10" test with better description and logging of what exactly it tests
Make task->residual a size_t instead of an int
Update and improve the log messages for failures for the read10 invalid test
TESTS: Add test for READ10 to check that over/underflow residuals are generated correctly.
TESTS: fixup a log message to be nore accurate
TESTS: Add tests for READ12/16 residuals
TESTS: Add tests that WRITE10/12/16 handle residuals correctly

Also test that IF the iSCSI layer provides 2 blocks of DATA-OUT but
the SCSI WRITE* command only covers one single block,
then only the first block will be modified but not the second block.
TESTS: Improve WRITE* residual tests and also check that we dont write too much if iSCSI EDTL < SCSI TL
TESTS: Add tests for residuals for WRITEVERIFY10/12/16
TESTS: Add tests to verify that RELEASE6 is dropped on target/lun reset
TESTS update reserve6 tests
SYNC Task mgmt functions. Return !0 status if the command completed successfully
but the target responded with non-zero response code.
TESTS: When task management functions fail, print the reason why it failed.
Make rpmbuild on F18 work

Steps:

1) ./autogen.sh
2) ./configure
3) sh packaging/RPM/makerpms.sh