VMCluster/VMAlertmanager: reject serviceSpec.type override with useAsDefault

[mehrdadbn9]

What

Follows up on #2487. As discussed in the issue, the default Service of vmselect, vmstorage and vmalertmanager is intentionally headless (clusterIP: None) because it also exposes cluster-native / gossip ports. Because of that, combining serviceSpec.useAsDefault: true with an explicit spec.type silently produces a service that is still headless - the user gets no error and no VIP, which is confusing.

Per the maintainer's suggestion in #2487 (comment) (prohibit overriding the service type for these components when useAsDefault: true), this PR makes the operator reject that combination with a clear error message instead of silently ignoring it.

Changes

• AdditionalServiceSpec.ValidateNoServiceTypeOverrideWithUseAsDefault(component) - new helper that rejects an explicit spec.type when useAsDefault is set.
• Wired into VMCluster.Validate() for vmselect and vmstorage.
• Wired into VMAlertmanager.Validate() for vmalertmanager.
• vminsert is intentionally left allowed: its default Service is not headless, so an explicit type override there works as expected.

Users who need a different service type can still create a separate additional Service by setting serviceSpec.useAsDefault: false with a distinct metadata.name.

Tests

Added unit test cases covering: reject for vmselect/vmstorage/vmalertmanager, allow when no explicit type is set, allow separate additional services, and allow type override for vminsert.

go build ./...          # OK
go vet ./operator/v1beta1/  # OK
go test ./operator/v1beta1/  # ok (full package)

Feedback welcome - happy to adjust the error message wording or the scope if you'd rather also cover vminsert.

[cubic-dev-ai]

All reported issues were addressed across 5 files

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[AndrewChubatiuk]

Thanks for a PR! Overall it's good, left some comments. Same changes probably should be propagated to all select and storage components as they also unconditionally set ClusterIP type

[AndrewChubatiuk]

please make this comment brief, it's a trivial check not need to have this multiline explanantion

[AndrewChubatiuk]

same is here, additionally no need to pass component name here,

[mehrdadbn9]

Thanks @AndrewChubatiuk — addressed the feedback:

• Shortened the helper GoDoc/rationale (it was a trivial check, no need for the multiline explanation).
• Removed the component parameter from ValidateNoServiceTypeOverrideWithUseAsDefault(); the error message no longer names a specific component.
• Corrected the rationale: the default service must stay headless (clusterIP: None) for cluster-native communication; an explicit spec.type with useAsDefault=true is rejected (per VMCluster: serviceSpec.useAsDefault cannot change vmselect Service from headless to ClusterIP #2487). (The earlier wording about "silently ignored" was inaccurate — build.Service does honor an explicit type override.)
• Applied to vmselect, vmstorage (VMCluster) and vmalertmanager.

On propagation to all select/storage components: I deliberately kept vminsert allowed, because its default Service is not headless (unlike vmselect/vmstorage/vmalertmanager), so an explicit type override there works as intended and shouldn't be rejected. If you'd still like vminsert covered (or the standalone CRDs like VMAgent/VMAlert/VMSingle), let me know and I'll extend it.

Force-pushed 84715de. Full api module test suite passes.