ci: add azure iptables monitor pipeline

[QxBytes]

Reason for Change:

Adds image publishing for azure iptables monitor to ACN Official Build pipeline and ACN PR pipeline
Merge after #3779

Issue Fixed:

Requirements:

• uses conventional commit messages
• includes documentation
• adds unit tests
• relevant PR labels added

Notes:
ACN PR: https://msazure.visualstudio.com/One/_build/results?buildId=129848847&view=results
ACN Build Pipeline: https://dev.azure.com/msazure/One/_build/results?buildId=129816140&view=results
ACN Unofficial Build: https://msazure.visualstudio.com/One/_build/results?buildId=129854515&view=results
which feeds into ACN Buddy Image Release: https://dev.azure.com/msazure/One/_build/results?buildId=129977665&view=results

After rebase:
ACN PR: https://msazure.visualstudio.com/One/_build/results?buildId=132175501&view=results
ACN Unofficial Build: https://msazure.visualstudio.com/One/_build/results?buildId=132175800&view=results

[Copilot]

Pull Request Overview

This PR adds the Azure iptables monitor component and wires it into the ACN build and release pipelines.

• Introduces the azure-iptables-monitor module with implementation, tests, and Dockerfile
• Updates go.mod, Makefile, and CODEOWNERS to include the new component
• Extends pipeline YAML and build scripts to publish the monitor image

Reviewed Changes

Copilot reviewed 12 out of 13 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
azure-iptables-monitor/iptables_monitor.go	implement monitoring logic and CLI entrypoint
azure-iptables-monitor/iptables_monitor_test.go	add unit tests for rule-matching functions
azure-iptables-monitor/go.mod	declare module path and dependencies
azure-iptables-monitor/README.md	document usage, pattern files, and flags
azure-iptables-monitor/Dockerfile	containerize the monitor binary
Makefile	add build/image/archive targets for the new component
.pipelines/run-pipeline.yaml	inject AZURE_IPTABLES_MONITOR_VERSION and jobs
.pipelines/pipeline.yaml	define monitor platforms and manifest stages
.pipelines/build/scripts/azure-iptables-monitor.sh	pipeline build script for the monitor
.pipelines/build/ob-prepare.steps.yaml	set output variable for monitor version
.pipelines/build/dockerfiles/azure-iptables-monitor.Dockerfile	pipeline Dockerfile for the monitor
.github/CODEOWNERS	add code owners for azure-iptables-monitor/

Comments suppressed due to low confidence (2)

.pipelines/run-pipeline.yaml:41

• The indentation of this line is two spaces less than the surrounding environment variables, which will break the YAML structure. Align it with the other entries.

 AZURE_IPTABLES_MONITOR_VERSION: $[ stageDependencies.setup.env.outputs['EnvironmentalVariables.azureIptablesMonitorVersion'] ] 

azure-iptables-monitor/iptables_monitor.go:95

• Consider adding unit tests for GetRules to verify chains are listed and rules are aggregated correctly, including error handling paths.

func GetRules(client IPTablesClient, tableName string) ([]string, error) { 

[QxBytes]

/azp run Azure Container Networking PR

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jpayne3506]

Lgtm, any plans to add azure-iptables image to make dockerfiles? Functionally it should make 0 difference as the final stage is distroless + iptables + binary, but it would keep our components base image at parity across the repo

azure-container-networking/Makefile

Lines 949 to 951 in 138e4f5

	dockerfiles: tools ## Render all Dockerfile templates with current state of world
	@make -f build/images.mk render PATH=cns
	@make -f build/images.mk render PATH=cni

[QxBytes]

Lgtm, any plans to add azure-iptables image to make dockerfiles? Functionally it should make 0 difference as the final stage is distroless + iptables + binary, but it would keep our components base image at parity across the repo

azure-container-networking/Makefile

Lines 949 to 951 in 138e4f5

	dockerfiles: tools ## Render all Dockerfile templates with current state of world
	@make -f build/images.mk render PATH=cns
	@make -f build/images.mk render PATH=cni

I can look into it but currently not too familiar with the process or the benefits esp if it seems like it'll be the same in the end?
Would this change also apply to other components other than cns and cni, ex: the ip masq merger?