Add SnippetsPolicy for Gateway level

[fabian4]

Problem: Users need a mechanism to inject raw NGINX configuration snippets into the generated configuration to leverage advanced NGINX features or directives that are not yet exposed via the Gateway API or existing NGINX Gateway Fabric policies.

Solution: Implemented the SnippetsPolicy Custom Resource Definition (CRD).

• API: The policy targets a Gateway and supports main, http, and server contexts.
• Validation: Added validation logic to enforce a maximum snippet size (2KB), ensure unique contexts per policy, and disallow unsupported contexts (e.g., http.server.location).
• Generation: The generator creates dedicated include files for each policy (e.g., includes/policy/<gateway>/SnippetsPolicy_main_...conf), ensuring clean separation of injected config.
• Integration: Wired the new policy into the ChangeProcessor, Controller Manager, and Helm charts.

Testing:

• Added unit tests for the Validator, Generator, and ChangeProcessor logic.
• Added a new integration test suite (tests/suite/snippets_policy_test.go) covering:
  • Valid snippets in all supported contexts.
  • Invalid context validation.
  • Duplicate context validation.
• Verified Helm chart generation.

Please focus on (optional): The validation logic in internal/controller/nginx/config/policies/snippetspolicy/validator.go, specifically the size limits and context checks.

Closes #4071

Checklist

Before creating a PR, run through this checklist and mark each as complete.

• I have read the
• I have added tests that prove my fix is effective or that my feature works
• I have checked that all unit tests pass after adding my changes
• I have updated necessary documentation
• I have rebased my branch onto main
• I will ensure my PR is targeting the main branch and pulling from my branch from my own fork

Release notes

 Added support for `SnippetsPolicy`, allowing users to inject custom NGINX configuration snippets into the `main`, `http`, and `server` contexts.

[nginx-bot]

Hi @fabian4!

Thanks for opening this pull request!
Be sure to check out our Contributing Guidelines while you wait for someone on the team to review this.

[sjberman]

Thanks for taking this on! It's not easy work.

[sjberman]

Per our SnippetsPolicy design, we should be able to support multiple TargetRefs. We can also just use LocalPolicyTargetReference, no need to alias.

[sjberman]

I think we also need to decide if we only want this to target Gateways, or also HTTP/GRPCRoutes. In our initial design, we proposed targeting all of these. However, I'm not convinced yet if we need it at the Route level. This could be enhanced in the future.

Based on the design here, this is a direct policy regardless, so we need the // +kubebuilder:metadata:labels="gateway.networking.k8s.io/policy=direct" label at the top level of the SnippetsPolicy struct.

[fabian4]

Allowing SnippetsPolicy to attach directly to Routes may overlap with existing mechanisms such as SnippetsFilter, introducing ambiguity around ownership and precedence. In the Gateway API model, Route behavior is typically defined within the Route, while Gateway-level policies focus on shared concerns. This separation feels clearer, though feedback is welcome.