The fix corrects an error in an if-predicate that checks which error codes
that should be propagated to the application (via TC). As it was, any error
code less than 6000 would cause the current row to be skipped, even those
codes that should have caused the query to be aborted.

This commit also fixes a related issue: If the scan aborts due to an error from
TUP and *no* rows had been sent to the API, the correct behavior is to return 
SCAN_FRAGREF to TC right away. If one or more rows has been sent, and locking 
is used, LQH should send a SCAN_FRAGCONF, wait for the next SCAN_NEXTREQ and 
then release the locks and then send SCAN_FRAGREF. As it was, LQH would send 
SCAN_FRAGCONF even when zero rows had been sent. This led to a situation where 
TC would eventually get a timeout while waiting for the api to close the scan.