set azuremonitoragent as primary group for azuremetricsext

[sajithmuh]

Summary

This fixes a bug in the CMv2 MetricsExtension service account setup where azuremetricsext could be created with its own private group as primary, while the service actually runs with azuremonitoragent as its group. In environments that manage /etc/passwd, this caused persistent primary GID mismatches, repeated account updates, and noisy security/config-management alerts.

Bug

The setup path used useradd without -g, which let the system fall back to the default user-private-group behavior. On machines where a pre-existing azuremetricsext group already existed, useradd failed instead of creating the user with the intended service group.

At the same time, the systemd unit runs ME as:

User=azuremetricsext
Group=azuremonitoragent

So the account creation logic and the service runtime identity were inconsistent.

Fix

• Create or ensure azuremetricsext with azuremonitoragent as its primary group.
• Make primary-group updates idempotent by skipping usermod -g when the user already has the expected primary group.
• Move optional extra access like himds to runtime SupplementaryGroups= in the systemd unit instead of persisting it in /etc/group.
• Make CMv2 runtime directory setup non-destructive across retry paths.
• Add defensive error handling and logging around user/group lookups and updates.

Result

• Fixes the useradd: group azuremetricsext exists ... use -g failure.
• Persisted account state now matches the intended CMv2 service identity.
• Repeated setup calls no longer unnecessarily rewrite the primary group.
• Supplementary access is scoped to the service process instead of permanently mutating group membership.

Validation

Validating in AMA Linux VM