securitycenter: make streaming_config.filter optional on NotificationConfig (#11021)

[jbbqqf]

Summary

Drop required: true from streamingConfig.filter on every variant of
google_scc_notification_config (organization / folder / project, both
securitycenter v1 and securitycenterv2). The SCC API marks the field
as optional in the wire format, and users have asked to omit it for "all
events" notifications.

Fixes hashicorp/terraform-provider-google#11021 — see hashicorp/terraform-provider-google#11021

Why

The Security Command Center notification API serializes
StreamingConfig.Filter with omitempty (see the vendored Go API
client securitycenter/v1/securitycenter-gen.go):

type StreamingConfig struct {
    // Filter: Expression that defines the filter to apply across
    // create/update events of assets or findings as specified by the
    // event type. ...
    Filter string `json:"filter,omitempty"`
    ...
}

omitempty on a non-pointer string means "skip the field on the wire if
unset", which the API documentation confirms by listing filter as
optional and saying "a list of zero or more restrictions". Yet the mmv1
schema marks streamingConfig.filter as required: true for all six
variants:

• mmv1/products/securitycenter/NotificationConfig.yaml
• mmv1/products/securitycenter/FolderNotificationConfig.yaml
• mmv1/products/securitycenter/ProjectNotificationConfig.yaml
• mmv1/products/securitycenterv2/FolderNotificationConfig.yaml
• mmv1/products/securitycenterv2/OrganizationNotificationConfig.yaml
• mmv1/products/securitycenterv2/ProjectNotificationConfig.yaml

So a user who wants notifications for every create/update event
(the natural "I just want everything" case) must invent a filter that
matches everything — there is no "always true" expression in the SCC
filter grammar and the trivial workarounds are awkward.

GCP API reference:

• NotificationConfig REST: https://cloud.google.com/security-command-center/docs/reference/rest/v1/organizations.notificationConfigs#StreamingConfig
• v2 NotificationConfig: https://cloud.google.com/security-command-center/docs/reference/rest/v2/organizations.locations.notificationConfigs#StreamingConfig
• "Filtering notifications" docs: https://cloud.google.com/security-command-center/docs/how-to-api-filter-notifications

What changed

Pure mmv1 schema change: removed the inner required: true from the
filter property in all six *NotificationConfig.yaml files. The
outer streamingConfig block is still required: true because every
NotificationConfig must specify a streaming config (that's the only
config kind the resource supports today).

mmv1/products/securitycenter/FolderNotificationConfig.yaml         | 1 -
mmv1/products/securitycenter/NotificationConfig.yaml               | 1 -
mmv1/products/securitycenter/ProjectNotificationConfig.yaml        | 1 -
mmv1/products/securitycenterv2/FolderNotificationConfig.yaml       | 1 -
mmv1/products/securitycenterv2/OrganizationNotificationConfig.yaml | 1 -
mmv1/products/securitycenterv2/ProjectNotificationConfig.yaml      | 1 -
6 files changed, 6 deletions(-)

After regen, the generated TPG schema for streaming_config.filter
becomes Optional: true instead of Required: true. No expand or
flatten code needed to change.

Edge cases tested

#	Scenario	HCL excerpt	Expected	Verified by
1	Filter omitted (the issue's case)	streaming_config { }	After: apply succeeds; resource gets created with empty filter (matches all events). Before: Error: Missing required argument: filter.	Static codegen check (Optional: true in generated schema) + make build clean
2	Filter set to a typical expression	filter = "category = \"OPEN_FIREWALL\" AND state = \"ACTIVE\""	Apply succeeds in both phases (existing examples already cover this).	mmv1 example scc_notification_config_basic
3	Filter changed from set to empty (update path)	filter = "" after a previous non-empty value	The streamingConfig.filter update mask is preserved (update_mask_fields: streamingConfig.filter is unchanged). API accepts empty filter on PATCH.	Static review: update_mask_fields block untouched

Test protocol

Test	Result	Notes
YAML lint (yq eval .) on all 6 files	OK
make build OUTPUT_PATH=... VERSION=ga	OK	mmv1 regen succeeds
go build ./google/services/securitycenter/... on regenerated TPG	OK	service compiles cleanly
go build ./... on full regenerated TPG	OK	full provider compiles
Live BEFORE/AFTER smoke	not run	this is a pure schema flag flip; the API already supports both code paths and the existing scc_notification_config_basic acceptance test covers the with-filter case. The without-filter case requires an SCC organization or folder, which the author does not have access to in the sandbox.

I'd appreciate maintainer verification on a sandbox SCC org if a live
acceptance run is desired before merge.

Resources

• Original issue: google_scc_notification_config has filter has mandatory for streaming_config even though it's not in the API hashicorp/terraform-provider-google#11021
• SCC v1 NotificationConfig API: https://cloud.google.com/security-command-center/docs/reference/rest/v1/organizations.notificationConfigs
• SCC v2 NotificationConfig API: https://cloud.google.com/security-command-center/docs/reference/rest/v2/organizations.locations.notificationConfigs
• Vendored Go client: google.golang.org/api@v0.278.0/securitycenter/v1/securitycenter-gen.go (StreamingConfig.Filter has json:"filter,omitempty")

Disclosure

This PR was drafted with assistance from Claude Code as part of a focused
contribution batch on TPG schema bugs. The diff was reviewed manually
against the GCP REST API documentation and the vendored Go client. The
mmv1 generation was run locally and the regenerated provider compiled
clean; a live BEFORE/AFTER smoke run was not done because the resource
needs a real SCC organization, which the author does not have set up.

The author (a human) reviewed the diff and the regenerated schema before
opening this PR.