docs: Document the NGF AccessPolicy API - #2336

Proposed changes

Documents the AccessPolicy API from nginx/nginx-gateway-fabric#5987, merged into the feat/access-policy feature branch. It ships with the next NGINX Gateway Fabric release. The feature is unreleased, so this PR targets ngf-release-next.

AccessPolicy (gateway.nginx.org/v1alpha1) is a new inherited policy for IP address allowlists and denylists on a Gateway, HTTPRoute, or GRPCRoute. #5987 adds the controller that watches AccessPolicies, their validation, and their status reporting. Changes in this PR:

• Adds content/ngf/traffic-security/access-policy.md, a how-to guide. It covers creating an AccessPolicy for a Gateway and for an HTTPRoute, checking the policy Accepted condition and the AccessPolicyAffected condition on the target, the spec fields and their limits, and two troubleshooting entries: CRD admission errors, and Accepted=False with reason Invalid for a bad IP address or CIDR range.
• Adds an AccessPolicy row to the policy table in content/ngf/overview/custom-policies.md. The row marks the policy as mergeable, because NGINX Gateway Fabric never reports an AccessPolicy as Conflicted.

Update for nginx/nginx-gateway-fabric#6013 (NGINX configuration generation for AccessPolicy, open against the feat/access-policy feature branch, next NGINX Gateway Fabric release): Adds a "How NGINX applies the access rules" section to the guide. It covers:

• What Allow and Deny do for requests that match no rule, the 403 Forbidden response, and a rule without source.
• How Gateway and route policies combine: Deny rules from both levels add up and come first, route Allow rules replace Gateway Allow rules, and a route without its own AccessPolicy uses the Gateway rules.
• Merging of several AccessPolicies with the same action on one resource.
• A table with the result for /coffee from the two example policies in the guide.
• The rewriteClientIP setting in NginxProxy for traffic behind a load balancer or proxy, with a link to the existing data plane configuration section.

#6013 isn't merged yet, so this section reflects its head commit 07a7a48. Recheck it if #6013 changes before merge. The AccessPolicy functional tests (nginx/nginx-gateway-fabric#5937) are still open.

content/ngf/reference/api.md is generated from the CRDs, so this PR doesn't edit it.

Update for the merged version of #5987: The final version of #5987 sets the AccessPolicyAffected condition on a Gateway or route only when the AccessPolicy is valid. The Gateway step now says that the condition shows a valid AccessPolicy targets the Gateway. The "The AccessPolicy status is Invalid" entry now says that an invalid AccessPolicy doesn't add the condition to its target. The merged version also changes how the controller parses addresses, but the condition message still starts with "must be a valid IPv4/IPv6 address or CIDR range", so the troubleshooting text is unchanged.

#5987 also adds a controller check that the apPolicyRef and apLogConfRef names in a WAFPolicy are valid DNS subdomain names. An invalid name sets Accepted=False with the reason Invalid. The existing Accepted row in the WAFPolicy troubleshooting page already covers spec validation failures, so this PR doesn't change the WAF pages.

Review feedback: Per review, the CRD error messages in the "Kubernetes rejects the AccessPolicy" troubleshooting entry are no longer formatted as whole-line code. Only the resource kinds and field names in each message (such as AccessRule, targetRefs, and IPAddress) keep code formatting. The message text is unchanged.

Review feedback (line 271): Declined the suggestion to replace "field" with "box" in the "The AccessPolicy status is Invalid" entry. The style guide's UI terms topic (terminology/ui-terms.md) calls for "box" only for UI input areas. Here "field" means the AccessPolicy spec field named in the condition message, such as spec.rules[0].source.ipAddress.address, which matches the Kubernetes API term used in the "AccessPolicy fields" section. On the same line, the condition message text is no longer formatted as code. It's now quoted as a literal string, matching the treatment of the CRD error messages, and the field path keeps code formatting.

Checklist

Before sharing this pull request, I completed the following checklist:

• I read the Contributing guidelines
• My branch adheres to the Git conventions
• My content changes adhere to the F5 Technical Writing Style Guide
• If my changes involve potentially sensitive information¹, I have assessed the possible impact
• I have waited to ensure my changes pass tests, and addressed any discovered issues