Feat: add bucket encryption enforcement configuration

[thiyaguk09]

Description

This PR implements support for Bucket Encryption Enforcement in the BucketMetadata interface. This feature allows users to restrict object creation based on specific encryption types (Google-managed, Customer-managed, or Customer-supplied).

Key Changes:

• Added googleManagedEncryptionEnforcementConfig, customerManagedEncryptionEnforcementConfig, and customerSuppliedEncryptionEnforcementConfig to the BucketMetadata interface.
• Included the server-generated effectiveTime (readonly) and restrictionMode fields for each configuration type.
• Added three new code samples: setBucketEncryptionEnforcementConfig, getBucketEncryptionEnforcementConfig, and removeAllBucketEncryptionEnforcementConfig.

Impact

This is a non-breaking feature addition. It enables security-conscious users to enforce CMEK-only (Customer-Managed Encryption Keys) policies at the bucket level, aligning the Node.js library with the latest GCS API capabilities.

Testing

• Unit Tests: Added coverage in test/bucket.ts to verify that metadata is correctly serialized into PATCH requests. All tests follow the recommended pattern of mocking the underlying request layer.
• System Tests: Added new test cases in system-test/storage.ts that execute the sample scripts against a live GCS project to verify end-to-end functionality and backend state persistence.
• Samples: Verified that all three new samples run successfully and produce human-readable output.

Additional Information

Note that effectiveTime is treated as a read-only field populated by the server, which is verified in the system tests.

Checklist

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Code coverage does not decrease
• Appropriate docs were updated
• Appropriate comments were added, particularly in complex areas or places that require background
• No new warnings or issues will be generated from this change

Fixes #🦕

[snippet-bot]

Here is the summary of changes.

You are about to add 3 region tags.

• samples/getBucketEncryptionEnforcementConfig.js:23, tag storage_get_encryption_enforcement_config
• samples/removeAllBucketEncryptionEnforcementConfig.js:23, tag storage_remove_all_encryption_enforcement_config
• samples/setBucketEncryptionEnforcementConfig.js:26, tag storage_set_encryption_enforcement_config

---

This comment is generated by snippet-bot.
If you find problems with this result, please file an issue at:
https://github.com/googleapis/repo-automation-bots/issues.
To update this comment, add snippet-bot:force-run label or use the checkbox below:

• Refresh this comment

[v-pratap]

Is the encryption property replaced entirely during a PATCH request? To me it does not appear to add deep-merge logic, If a user updates an enforcement setting using this example, any existing defaultKmsKeyName will be deleted unless they manually include it in the object.

[v-pratap]

Can you also look into the tests related to this code?

[thiyaguk09]

I’ll take a look at this and let you know soon.

[thiyaguk09]

@v-pratap You're right that the library performs a shallow patch. However, I’ve verified via a new integration test that the Cloud Storage API handles the deep merge on the backend.

When sending a patch with only enforcement settings, the API correctly retains the existing defaultKmsKeyName. I have added an integration test (should retain defaultKmsKeyName when updating enforcement settings independently) to confirm this behavior and prevent any future regressions. Since the backend manages this strategically, additional merge logic in the client isn't required.