Fixing size parameter handling in len-mechanism to handle function parameters with different size parameters

[batzuu]

• This contribution adheres to CONTRIBUTING.md.
• I've updated CHANGELOG.md if applicable.
• I've added tests applicable for this pull request

What does this Pull Request accomplish?

Fixes the codegen to properly handle functions with multiple array parameters that reference different size parameters:

• Updates metadata_filters.py: Refactors the filter_parameters function to collect all size parameter names referenced by len-sized parameters into a len_size_parameter_names, replacing the previous single len_size_parameter approach. Removed assert to check if all size parameters are same from filter_len_parameters. Following this updated var names in default_method.py.mako and initialization_method.py.mako to reflect multiple possible size params.

• Updates to nifake to enable testing: Details covered in testing section

Previously, it was assumed all len-mechanism arrays in a function shared the same size parameter. This change enables functions like CreateDeembeddingSparameterTableArray in NI-RFSG where frequencies uses frequenciesSize and sparameterTable uses sparameterTableSize.

List issues fixed by this Pull Request

Issue 2137: Fix size parameter handling for functions with parameters referencing multiple size parameters.
Additional PR needs to be raised to update NI-RFSG function metadata (CreateDeembeddingSparameterTableArray) to consume
these changes.

What testing has been done?

• Added MultipleArraysDifferentSize function to nifake metadata with two arrays (valuesArray using valuesArraySize, and dataArray using dataArraySize) to test the change in filter param logic
• Added unit test test_multiple_arrays_different_size in test_library_interpreter.py that verifies correct handling of multiple arrays with independent size parameters
• Test validates that each array's length is properly calculated and passed with its corresponding size parameter (3 elements for valuesArray with valuesArraySize, and 5 elements for dataArray with dataArraySize)
• All existing tests continue to pass.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 62.50000% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.16%. Comparing base (7712396) to head (bd858fd).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
build/helper/metadata_filters.py	63.63%	4 Missing ⚠️
generated/nifake/nifake/_grpc_stub_interpreter.py	50.00%	1 Missing ⚠️
generated/nifake/nifake/session.py	66.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2138      +/-   ##
==========================================
+ Coverage   81.72%   89.16%   +7.44%     
==========================================
  Files          29       71      +42     
  Lines        4115    18968   +14853     
==========================================
+ Hits         3363    16913   +13550     
- Misses        752     2055    +1303     

Flag	Coverage Δ
codegenunittests	84.35% <63.63%> (-0.10%)	⬇️
nidcpowersystemtests	94.65% <ø> (?)
nidcpowerunittests	89.53% <ø> (ø)
nidigitalsystemtests	92.26% <ø> (?)
nidigitalunittests	68.44% <ø> (ø)
nidmmsystemtests	92.72% <ø> (?)
nifakeunittests	85.41% <60.00%> (-0.11%)	⬇️
nifgensystemtests	94.61% <ø> (?)
nimodinstsystemtests	73.85% <ø> (?)
nimodinstunittests	94.20% <ø> (ø)
nirfsgsystemtests	76.53% <ø> (?)
niscopesystemtests	92.94% <ø> (?)
niscopeunittests	43.20% <ø> (ø)
nisesystemtests	91.50% <ø> (?)
niswitchsystemtests	82.03% <ø> (?)
nitclksystemtests	94.87% <ø> (?)
nitclkunittests	98.26% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
generated/nifake/nifake/_grpc_stub_interpreter.py	82.80% <50.00%> (-0.27%)	⬇️
generated/nifake/nifake/session.py	77.43% <66.66%> (-0.07%)	⬇️
build/helper/metadata_filters.py	71.69% <63.63%> (-1.12%)	⬇️

... and 46 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7712396...bd858fd. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ni-jfitzger]

generated/nidcpower/nidcpower/_library_singleton.py:43:5: F824 global _instance_lock is unused: name is never assigned in scope
global _instance_lock

It seems we've gone from using flake8 7.1.2 to using flake8 7.3.0 and the new one has this new error code.
It doesn't like that we're using global here but never assigning a value to _instance_lock in that scope.
Though, according to the documentation, you need to declare with global before you can even use the variable.

https://docs.python.org/3/reference/simple_stmts.html#the-global-statement

This seems like something we should address in a separate PR.

[bkeryan]

Though, according to the documentation, you need to declare with global before you can even use the variable.

https://docs.python.org/3/reference/simple_stmts.html#the-global-statement

This seems like something we should address in a separate PR.

You only need the global keyword to assign global variables from an inner scope, not to read them.

https://stackoverflow.com/questions/291978/short-description-of-the-scoping-rules
https://docs.python.org/3/reference/executionmodel.html#resolution-of-names

[batzuu]

It seems we've gone from using flake8 7.1.2 to using flake8 7.3.0 and the new one has this new error code. It doesn't like that we're using global here but never assigning a value to _instance_lock in that scope. Though, according to the documentation, you need to declare with global before you can even use the variable.

https://docs.python.org/3/reference/simple_stmts.html#the-global-statement

This seems like something we should address in a separate PR.

I have added a noqa to suppress the flake8 warning so that this PR can merge. The actual issue we will address in a separate PR.