Change optional filter ordering

[jthorton]

Fixes #61 by applying additional filters before the default ring-based filters to ensure rings are not broken when requested.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.60%. Comparing base (c2855ed) to head (1d69472).
Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #64   +/-   ##
=======================================
  Coverage   96.60%   96.60%           
=======================================
  Files          13       13           
  Lines         618      618           
=======================================
  Hits          597      597           
  Misses         21       21           

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

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests

[hannahbaumann]

Thanks @jthorton , lgtm, just that one question!

[hannahbaumann]

What would happen if you include the default filters in the additional mapping filters, would it skip them/still preserve the correct order?
E.g.

additional_mapping_filter_functions=[
                filter_ringbreak_changes, # default
                filter_ringsize_changes, # default
                filter_whole_rings_only, # default
                filter_hybridization_changes]

[jthorton]

We currently don't check what filters are passed as additional so if a default filter was used then it would be applied twice first as an additional filter then as the default, maybe I should expand the docs to make it clear that defaults are applied first?

[IAlibay]

Is this the behaviour we want to have?

Long term I could see a case where folks would want to chain custom filters so that they can iteratively patch some behaviour - however in this case where we have named filters vs custom ones, would it make sense to just error out (or at least warn) if the method is already in _filter_funcs?

[jthorton]

I think a warning would be fair we don't want to error out and stop experimentation and a section in the docs which explains exactly which filters are applied when you set a default filter should help.

[IAlibay]

overall lgtm, but would be good to work out what we want our default behaviour to be.

[IAlibay]

Is this the behaviour we want to have?

Long term I could see a case where folks would want to chain custom filters so that they can iteratively patch some behaviour - however in this case where we have named filters vs custom ones, would it make sense to just error out (or at least warn) if the method is already in _filter_funcs?