Use a dynamic cutoff to limit number of variants to consider as combination in a variant bubble

[zhuchcn]

This should fix the hypermutated region in a more flexible way. Here a cutoff value is set dynamically based on the total number of variants in a variant bubble. The cutoff value is set such that the total number of variant combinations won't be too much more than 5000.

Closes #738

Description

Closes #...

Checklist

• This PR does NOT contain PHI or germline genetic data. A repo may need to be deleted if such data is uploaded. Disclosing PHI is a major problem.
• This PR does NOT contain molecular files, compressed files, output files such as images (e.g. .png, .jpeg), .pdf, .RData, .xlsx, .doc, .ppt, or other non-plain-text files. To automatically exclude such files using a .gitignore file, see here for example.
• I have read the code review guidelines and the code review best practice on GitHub check-list.
• The name of the branch is meaningful and well formatted following the standards, using [AD_username (or 5 letters of AD if AD is too long)]-[brief_description_of_branch].
• I have added the major changes included in this pull request to the CHANGELOG.md under the next release version or unreleased, and updated the date.
• All test cases passed locally.

[lydiayliu]

How is this related to the max-variants-per-node parameter? is self.cleavage_params.max_variants_per_node no longer used anywere?

We can set it up so that if the parameter is set lower than max_in_bubble_variants then we use the parameter value instead? Maybe some users dont want any variant combinations?

[zhuchcn]

How is this related to the max-variants-per-node parameter? is self.cleavage_params.max_variants_per_node no longer used anywere?

The max_variants_per_node is still used in PeptideVariantGraph, when converting it into a cleavage graph. It's also used when calling miscleavaged peptides, together with additional_variants_per_misc.

We can set it up so that if the parameter is set lower than max_in_bubble_variants then we use the parameter value instead? Maybe some users dont want any variant combinations?

I think setting a hard cutoff of max_variants_per_node isn't very appropriate here, because the complexity depends on the total number of variants in a variant bubble. The more variants in a bubble, the fewer max_in_bubble_variants that we can support.