[feat] Check that read pairs have the same name

[nh13]

The read name checked include only the header line up to the first white-space. The remaining header is ignore.

Fixes #26.

[nh13]

My only concern is that this may be expensive, since this will be done for every read.

[tfenne]

I totally agree and would be hesitant to merge this as is without some benchmarking. A couple of alternative suggestions for @jiangweiyao and @omicsorama to weigh in on:

1. Would it be sufficient to check the either just the first record, or the first and last in each RecordSet, either here or perhaps upon construction of the PerFastqRecordSet (where we already validate that the record sets are the same length).
2. If (1) is not sufficient, we could also e.g. check every nth record here. E.g. if we checked every 50th or 100th record that would catch the vast majority of issues with a lot less performance overhead.

More generally - what's the problem we are trying to solve? Catching when a user mixes up FASTQ files can be done by checking first/last etc. But if we're trying to catch broken upstream software that might occasionally emit reads in differing order that would dictate checking every read on the way through.

[nh13]

See #27 where I added in checking just the first read in each file (implicitly does not allow empty input FASTQs).

[tfenne]

Suggestion for a more performant (I think) approach.
But more importantly I think we need to understand the goal, and that can inform whether we need to check every read, or just enough to catch user error.

[tfenne]

I think you could do this more efficiently as follows:

            let first_head = zipped_reads[0].head();
            let end_index = zipped_reads[0].head().find_byte(b' ').unwrap_or(first_head.len());
            for read in zipped_reads.iter().dropping(1) {
                let head = read.head();
                let ok = head.len() >= end_index && first_head[0..end_index] == head[0..end_index];
                ensure!(ok, ...);
            }

This calculates the region of the first header that is the read name, and then for subsequent reads checks they have at least that many characters, and that they match. This avoids scanning all but the first read, and I think it does that more efficiently too. For bonus points you could also double-check that each read header stops after end_index or that head[end_index] == b' '.

[nh13]

For my future self:

let head = record.head();
let ok = head.len() == end_index || (head.len() > end_index && head[end_index] == b' ');
let ok = ok && first_head[0..end_index] == head[0..end_index];

[tfenne]

I totally agree and would be hesitant to merge this as is without some benchmarking. A couple of alternative suggestions for @jiangweiyao and @omicsorama to weigh in on:

1. Would it be sufficient to check the either just the first record, or the first and last in each RecordSet, either here or perhaps upon construction of the PerFastqRecordSet (where we already validate that the record sets are the same length).
2. If (1) is not sufficient, we could also e.g. check every nth record here. E.g. if we checked every 50th or 100th record that would catch the vast majority of issues with a lot less performance overhead.

More generally - what's the problem we are trying to solve? Catching when a user mixes up FASTQ files can be done by checking first/last etc. But if we're trying to catch broken upstream software that might occasionally emit reads in differing order that would dictate checking every read on the way through.