feat: add gh issue label logic

[rahalan]

Description

For all open AVM issue, assignment of the module owner or orphaned label assignment is checked and corrected.

Pipeline Reference

Pipeline

Type of Change

• Update to CI Environment or utilities (Non-module affecting changes)
• Azure Verified Module updates:
  • Bugfix containing backwards-compatible bug fixes, and I have NOT bumped the MAJOR or MINOR version in version.json:
    • Someone has opened a bug report issue, and I have included "Closes #{bug_report_issue_number}" in the PR description.
    • The bug was found by the module author, and no one has opened an issue to report it yet.
  • Feature update backwards compatible feature updates, and I have bumped the MINOR version in version.json.
  • Breaking changes and I have bumped the MAJOR version in version.json.
  • Update to documentation

Checklist

• I'm sure there are no other open Pull Requests for the same update/change
• I have run Set-AVMModule locally to generate the supporting module files.
• My corresponding pipelines / checks run clean and green without any errors or warnings

[eriqua]

If the logic is the same I'd suggest a single platform pipeline, running on schedule as well as on issue creation (issues types [opened])

[rahalan]

@eriqua it is the same logic, but the issue creation one only looks into one issue (the new one), while the scheduled one looks at all open issues, so there is a loop into it, that calls the other logic

[eriqua]

My suggestion would be to merge the 2 and use github.event_name to check which event triggered the workflow. Based on that call the corresponding intended logic.

However, given another PR #4987 was opened meanwhile and updating some of the common logic, I'd suggest to have this PR in to allow the review of the other one. Then, think about the optimization later.

[eriqua]

Was the logic tested locally? I'd suggest the following test coverage:

1. create a test issue on an owned module, run the logic and verify the owner is assigned
2. assign the orphaned label on the owned test issue, run the logic and verify the label is removed
3. create a test issue on an orphaned module, run the logic and verify the orphaned label is assigned
4. assign an owner to the orphaned test issue, run the logic and verify the owner is unassigned