Require both overlap and breakend proximity for depth-only SV clustering

[mwalker174]

SV clustering uses both reciprocal overlap and a maximum endpoint distance criteria. Currently, calls with only depth evidence are clustered differently from other classes in that only one of these two is required. However, this is confusing, unnecessary, and problematic in certain cases (it was convenient originally for the first modules ported in GATK-SV).

This PR changes depth-only calls to be treated as other classes, requiring both criteria to be met.

Note that increasing the endpoint window to a very high number (10Mbp) effectively retains the original behavior and is now the default value.

[cwhelan]

Two questions:

getMaxClusterableStartingPositionWithParams in CanonicalSVLinkage uses the window to determine the max clusterable position. Will setting the value to 10MB make everything look clusterable to this method, potentially bogging down the algorithm for large callsets?

Is there a reason to keep the keep the old code around if this is the intended way to disable the proximity check (setting the window very large)? Seems like an opportunity to simplify if you don't want to support that special case anymore.

[mwalker174]

Two questions:

getMaxClusterableStartingPositionWithParams in CanonicalSVLinkage uses the window to determine the max clusterable position. Will setting the value to 10MB make everything look clusterable to this method, potentially bogging down the algorithm for large callsets?

getMaxClusterableStartingPositionWithParams should be smart enough to use enough both the window and reciprocal overlap to calculate the max position, taking the min of the two if both are required. Effectively we're just disabling the window requirement so the RO will always be used I think.

Is there a reason to keep the keep the old code around if this is the intended way to disable the proximity check (setting the window very large)? Seems like an opportunity to simplify if you don't want to support that special case anymore.

I was thinking of doing that, but we're probably also going to start doing some experimenting with new clustering strategies in the near future so I wanted to keep it in just in case. I'll add a comment noting that the AND vs OR functionality is not used anymore.

[cwhelan]

Sounds reasonable, looks good to me.