feat: raise exception if CollectDuplexSeqMetrics run on consensus BAM

[znorgaard]

Closes #992.

This PR adds a new isConsensusRead method to Umis.scala which is then used in CollectDuplexSeqMetrics to raise an exception if the first record is a consensus record.

In addition to the unit tests, I ran this on a consensus BAM locally and generated the expected error message. Running on the preceding grouped BAM generated the expected outputs as well.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.62%. Comparing base (9a4b01d) to head (c3aa60c).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1003   +/-   ##
=======================================
  Coverage   95.62%   95.62%           
=======================================
  Files         126      126           
  Lines        7382     7388    +6     
  Branches      497      510   +13     
=======================================
+ Hits         7059     7065    +6     
  Misses        323      323           

Flag	Coverage Δ
unittests	95.62% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tfenne]

A couple of thoughts here:

1. Is it necessary to check each and every read? Or could you add .bufferBetter to the construction of _filteredIterator and then just check the first element?
2. I think this is a case where a much more comprehensive error message would be useful, something like:

Input BAM file to CollectDuplexSeqMetrics ($input) appears to contain consensus reads.
CollectDuplexSeqMetrics cannot run on consensus BAMs, and instead requires the UMI-grouped BAM prior to consensus calling.  The UMI-grouped BAM is the output of running
GroupReadsByUmi.

First record in $input has consensus tags present:
${_filteredIterator.peek()}

[znorgaard]

For the first point, I think it depends on what we're trying to guard against. If we're only guarding against a well formed consensus BAM being input then I think checking the first record should work.

If we're guarding against all the chaos a user may concoct, then this will not be sufficient. But, I think guarding against all those possibilities is probably unnecessary and unrealistic.

[clintval]

Looking good! I do like the buffered and peek approach since a SAM/BAM is likely to have all the records with the tags, or none of them (in the non-corrupt example), so checking the first should be sufficient to catch 99%+ of improper inputs.

[clintval]

This works well for me! Thanks Zach! @tfenne could you give a final review?

[nh13]

A few suggestions, but lgtm

All comments addressed, Tim is OOO