fix(check): add deviceregistry Device evaluation for namespaced API

[ketkimnaik]

We have namespace devices now in az iot ops check --svc deviceregistry :

With status object:

---

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

Thank you for contributing to Azure IoT Operations tooling!

This checklist is used to make sure that common guidelines for a pull request are followed.

General Guidelines

Intent for Production

• It is expected that pull requests made to default or core branches such as dev or main are of production grade. Corollary to this, any merged contributions to these branches may be deployed in a public release at any given time. By checking this box, you agree and commit to the expected production quality of code.

Basic expectations

• If introducing new functionality or modified behavior, are they backed by unit and/or integration tests?
• In the same context as above are command names and their parameter definitions accurate? Do help docs have sufficient content?
• Have all the relevant unit and integration tests pass? i.e. pytest <project root> -vv. Please provide evidence in the form of a screenshot showing a succesful run of tests locally OR a link to a test pipeline that has been run against the change-set.
• Have linter checks passed using the .pylintrc and .flake8 rules? Look at the CI scripts for example usage.
• Have extraneous print or debug statements, commented out code-blocks or code-statements (if any) been removed from the surface area of changes?
• Have you made an entry in HISTORY.rst which concisely explains your user-facing feature or change?

Azure IoT Operations CLI maintainers reserve the right to enforce any of the outlined expectations.

A PR is considered ready for review when all basic expectations have been met (or do not apply).

[digimaun]

The command supports filtering by resource type via --resources. One part is adding the namespace devices and assets to that list. But here, what is the experience if the user passes in az iot ops check --svc deviceregistry --resources assetendpointprofile or in the higher up check_post_deployment( api_info=DEVICEREGISTRY_API_V1, ...) processes az iot ops check --svc deviceregistry --resources device?

[digimaun]

Or another way to put is if it's better to have conditions based on if the resource kind belongs to the API.

[ketkimnaik]

Fixed — resource_kinds is now pre-filtered per API group before being passed to each check_post_deployment call. If a requested kind doesn't belong to that group, the entire call is skipped rather than inadvertently running all evaluations with an empty filter.

[digimaun]

an observation that this is the same patch as the fixture above it, so if there is a case that they both need to be used at the same time, the last patch wins

[ketkimnaik]

Good catch! I merged both fixtures into a single one using a side_effect that dispatches on api_info.group, so the correct target name is returned regardless of which API group is under test. mock_generate_deviceregistry_device_target_resources is now just an alias pointing to the same fixture, so there's only ever one patch registered on generate_target_resource_name per test.

[digimaun]

mocker is a special name in this context, lets call this variable something else. Maybe mock_get_resources?

[ketkimnaik]

Renamed to mock_get_resources, but since it was unused (no call assertions needed) dropped the assignment entirely — the patch is still active.