feat: expose PropertyFieldsContainer class properly

[moe-ad]

Closes #2152, Closes #2142.

Summary

• _MockPropertyFieldsContainer class removed.
• PropertyFieldsContainer class added. This subclasses the Collection class, and no extra methods have been added at the moment.
• Test cases added.
• The code generation scripts have been updated to detect and correct references like 'Class DataProcessing::DpfTypeCollection<Class DataProcessing::CPropertyField>'.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.39%. Comparing base (f184fc2) to head (bf43ccc).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2816      +/-   ##
==========================================
- Coverage   84.43%   84.39%   -0.05%     
==========================================
  Files          92       92              
  Lines       10964    10845     -119     
==========================================
- Hits         9258     9153     -105     
+ Misses       1706     1692      -14     

[moe-ad]

@PProfizi I have some concerns about potential inconsistencies in operators API if this PR gets merged as is.

Currently, PropertyFieldsContainer references in various forms are being detected and updated to PropertyFieldsCollection references in the wrapped operators. However, if these references aren't changed server side, there will be API differences between the legacy way of using operators vs modern wrapped operators. See a concrete example below to understand what I am talking about:

from ansys.dpf import core as dpf

identical_pfc_op = dpf.Operator("compare::property_fields_container")
print(identical_pfc_op.inputs)
# Available inputs:
#      -   property_fields_containerA : PropertyFieldsCollection
#      -   property_fields_containerB : PropertyFieldsCollection

identical_pfc_op2 = dpf.operators.logic.identical_pfc()
print(identical_pfc_op2.inputs)
# Available inputs:
#      -   property_fields_collectionA : PropertyFieldsCollection
#      -   property_fields_collectionB : PropertyFieldsCollection

I am sure about how we should proceed in this case.

[PProfizi]

@PProfizi I have some concerns about potential inconsistencies in operators API if this PR gets merged as is.

Currently, PropertyFieldsContainer references in various forms are being detected and updated to PropertyFieldsCollection references in the wrapped operators (). However, if these references aren't changed server side, the will be API differences between the legacy way of using operators vs modern wrapped operators. See a concrete example below to understand what I am talking about:

from ansys.dpf import core as dpf

identical_pfc_op = dpf.Operator("compare::property_fields_container")
print(identical_pfc_op.inputs)
# Available inputs:
#      -   property_fields_containerA : PropertyFieldsCollection
#      -   property_fields_containerB : PropertyFieldsCollection

identical_pfc_op2 = dpf.operators.logic.identical_pfc()
print(identical_pfc_op2.inputs)
# Available inputs:
#      -   property_fields_collectionA : PropertyFieldsCollection
#      -   property_fields_collectionB : PropertyFieldsCollection

I am sure about how we should proceed in this case.

You are right. When we discussed whether the property_fields_container was exposed already, we concluded that it was not, but there are actually some operators which expose it at least as output types and thus pin names...
I think we'll have to stick with PropertyFieldsContainer as a name for the class and type for now.
Sorry about this.

[moe-ad]

@PProfizi operator changes that we need to merge are here: #2829

[PProfizi]

Thanks Moe, just a few comments!

[github-actions]

Some tests with 'continue-on-error: true' have failed:

• PyDPF-Post docstring tests on windows-latest

• PyDPF-Post API tests on windows-latest

• PyDPF-Post docstring tests on ubuntu-latest

• PyDPF-Post API tests on ubuntu-latest

  Created by continue-on-error-comment