Fix Adam2fastq in case of read with both reverse and unmapped flags

[jpdna]

Fixes the bug in fastq dump discussed in #980
specifically for case of a read that has both reverse and unmapped flags set in the input bam file.

[AmplabJenkins]

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/1122/
Test PASSed.

[heuermh]

could you create a new unit test instead of modifying this existing one? it is better to always be increasing unit test coverage

[jpdna]

The test as it is was previously written handled the case which it was then testing, which was the case of reverse stand flag with negative flag, incorrectly and thus failed with the changes introduced by this PR. I modified the test to be correct, and the change in the message above to converting to fastq with unmapped reads when read reverse strand flag was set just describes the test more specifically.

[fnothaft]

I would agree with @heuermh; specifically, I would fix the current test, and add a new test that tests the "unmapped + reverse strand flag" case.

[fnothaft]

Other than the test case nit, LGTM!

[AmplabJenkins]

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/ADAM-prb/1127/
Test PASSed.

[fnothaft]

Thanks for the test fix! Can you squash down and rebase? @heuermh if it looks good to you, I will merge.

[heuermh]

+1

[jpdna]

I updated PR so that tests cover correctly both umapped with Ox10 set and unset. The existing test did need to be revised as it was incorrect before. I had to add a the new test using different different records because actually the case which was not covered previously was the case of umapped without Ox10 set, and required a different record to test.

I also revised to be consistent what was previously a confusing re-ordering of (firstRecord,SecondRecord) here when return tuple values are assigned in these tests. As far as I can tell first and second here only refer to the order in which they appear in the input SAM file, and the assertion of

assert(firstRecord.getReadInFragment === 1)
assert(secondRecord.getReadInFragment === 0)

or

assert(firstRecord.getReadInFragment === 0)
assert(secondRecord.getReadInFragment === 1)

is more clear if the tuple order remains the same and the val names are not switched when parsing the tuple.

And yes - I'll squash and rebase

[fnothaft]

Actually, I can take care of the rebase + squash when merging. I'll merge this now...

[fnothaft]

Thanks @jpdna! Squashed and merged as b8e36b2.