General: Unify profile filter criteria in code

[BigRoy]

Description

Profile filtering is done in a myriad of locations in the code and in some areas I think can be unified to avoid logic differences and errors.

As an example:

• In subset_name_profiles the last part of the family name is used.
• In the current integrator (before refactor) the full family name is used - same as in Collect Ftrack Family
• The Collect Ftrack Family plug-in uses api.Session["AVALON_APP"] for the hosts filter criteria whereas the Integrator uses context.data["host_name"]
• The filter criteria also came up on this PR just now which recommends using context.data["hostName"] which however CAN be different from api.Session["AVALON_APP"] which as listed above is potentially also wrongly used in some areas of the code?
• The Collect Ftrack Family plug-in filter criteria doesn't expose the task_type entry in the filter criteria even though the Admin settings does expose it. This seems like a bug which I think can be traced back to not having a clear definition and entry point for these filter criteria.

I'm aware the filter_profiles is also used in other ways with other filter criteria. However it seems like a bunch of areas use the same filter criteria but seemingly with little consistency? At this point in time I'm mostly targeting those filtering criteria using

Even better if we could also unify this in Admin Settings with its own Profile Filter Schema for the settings - so that if we change the schema and the function all areas support the extra filtering features, like how it appears "Task Type" was added at a later state but not correctly implemented in some areas?

Describe the solution you'd like

Preferably expose a get_profile_filter_criteria method that clearly describes what it expects as input values. Or find another way to ease profile filtering in the many different locations in the code base.

In the Integrator Refactor I tried to use the simplest data source that is accessible that had the 'right' formatting compared to what the old integrator was doing and turn that into get_profile_filter_criteria and made it use only the parsed anatomyData. Not saying that's the good way and I'd definitely love to include that in this Issue/discussion.

Additionally I think we can get by by having a single collect_profile_filter_criteria Collector so that other plug-ins could even use the cached instance.data["profile_filter_criteria"] or alike. Not sure if better but at least it'd mean consistent across the publishing workflow.

Nonetheless I feel the urge to just have an easily accessible and consistent way to create the filter criteria would be beneficial.

[cuID:OP-2989]