CRAM incorrectly reporting success after malloc failure on read using threads

Start with test/test_view and the sam_read1() path, then inspect cram_eof(), cram_dopen(), cram_read_container(), and the error paths in cram/cram_decode.c. Reproduce the threaded malloc failure with the commands in the issue and trace where the EOF flag remains set. Done means the read reports failure and returns a nonzero status instead of success.

To reproduce, build HTSlib with @jkbonfield 's malloc testing framework. Create a small cram file:

FUZZ=1000000 ./test/test_view -C -t test/ce.fa test/ce#1000.sam > /tmp/ce#1000.cram

Try to read it back, but trigger a malloc failure. It will only print the header, log error messages but return success:

$ FUZZ=422 ./test/test_view -@ 2 -t test/ce.fa /tmp/ce#1000.cram
@SQ	SN:CHROMOSOME_I	LN:1009800	M5:8ede36131e0dbf3417807e48f77f3ebd	UR:/nfs/users/nfs_r/rmd/git/htslib/test/ce.fa
@SQ	SN:CHROMOSOME_II	LN:5000	M5:8e7993f7a93158587ee897d7287948ec	UR:/nfs/users/nfs_r/rmd/git/htslib/test/ce.fa
@SQ	SN:CHROMOSOME_III	LN:5000	M5:3adcb065e1cf74fafdbba1e8c352b323	UR:/nfs/users/nfs_r/rmd/git/htslib/test/ce.fa
@SQ	SN:CHROMOSOME_IV	LN:5000	M5:251af66a69ee589c9f3757340ec2de6f	UR:/nfs/users/nfs_r/rmd/git/htslib/test/ce.fa
@SQ	SN:CHROMOSOME_V	LN:5000	M5:cf200a65fb754836dcc56b24b3170ee8	UR:/nfs/users/nfs_r/rmd/git/htslib/test/ce.fa
Malloc fail after 422 allocs at cram/cram_io.h:513
Malloc fail after 422 allocs at thread_pool.c:105
[E::cram_next_slice] Call to hts_tpool_next_result failed
$ echo $?
0

This is because sam_read1() calls cram_eof() to distinguish EOF from error, and in this case the cram eof flag is set. Note that following PR #91 the EOF flag is set in cram_dopen() and later cleared in cram_read_container(). This means there are places where failures can occur when it's set. A few of these set fd->eof = 0 before returning so the error gets reported, but it seems there are places where this isn't done.