Fixed an edge case in HaplotypeCaller where filtered alleles in the vicinity of forced-calling alleles could result in empty calls

[jamesemery]

Fixes #7741

[jamesemery]

@davidbenjamin you are on the git blame here but you might not be the one to review. A user complained about empty calls in the vicinity of force calling alleles like this:chr5 125895106 . G . 13.34 . AN=2;DP=31;MQ=59.46 GT:AD:DP 0/0:31:31 https://gatk.broadinstitute.org/hc/en-us/community/posts/4664460343195-Haplotypecaller-4-5-2-0-alleles-unexpected-output. It turns out what was happening is that on the same assembly window as a genuine force-calling allele if there are variants that get genotyped as het variants but fall below our filtering threshold for allele calling there was a bug where we would not kick out of constructing the output VC for that site and consequently we will end up calling a empty hom ref call even if we don't intend to.

[davidbenjamin]

@jamesemery I will gladly review. If I understand the code change it seems like there was already basically the right logic to avoid this but the code was neglecting to put the force calling alleles in a representation consistent with the output VCF. And the fix is simply to compute forcedAlleles = AssemblyBasedCallerUtils.getAllelesConsistentWithGivenAlleles(givenAlleles, vc) a bit upstream of where we were doing so previously. If I've got that right, this PR gets my 👍.

[davidbenjamin]

This is entirely sensible.

[jamesemery]

@davidbenjamin looks like i have to wait for the test to pass because travis is having problems. What was happening is that the list of alleles didn't necessarily overlap with the VC being evaluated here (the AssemblyBasedCallerUtils.getAllelesConsistentWithGivenAlleles(givenAlleles, vc) was among other things responsible for filtering out alleles that don't overlap the site at all. This was responsible for the users issue because there were alleles from adjacent --alleles file variants 20 bases downstream that caused that condition to fail.

[droazen]

Need a test that demonstrates the issue

[jamesemery]

@droazen I added a test with some documentation about the issue and the no-calls.

Tests added as requested

[jamesemery]

@davidbenjamin Can you look at the test? I didn't want to check in a file with the old erroneous behavior so its hard to demonstrate what this fixed but i tried to make it clear in the comments.

[gatk-bot]

Travis reported job failures from build 38317
Failures in the following jobs:

Test Type	JDK	Job ID	Logs
variantcalling	openjdk8	38317.4	logs

[davidbenjamin]

@jamesemery The test looks good. I am averse to exact match tests and would prefer to just strea the VCF output and check for empty calls. Nonetheless, I understand that there's a tradition of exact match tests in some of our tools. I leave it up to you.