Per maintainer feedback on envoyproxy#8955, replace the implicit
"nil clientIPDetection ⇒ use downstream remote address" behavior
introduced in the previous commit with an explicit new field:
ClientTrafficPolicy.spec.clientIPDetection.downstreamRemoteAddress.

Triggering the new behavior on absence of clientIPDetection was a
fail-open footgun: an operator forgetting to set XFF behind a NATing
proxy would silently trust the wrong IP for geolocation. The explicit
field makes the operator's intent unambiguous.

API:
* Add DownstreamRemoteAddressSettings (empty struct, room to grow) and
  the DownstreamRemoteAddress field on ClientIPDetectionSettings.
* Update the CEL XValidation rule to enforce mutual exclusion across
  all three siblings (xForwardedFor, customHeader, downstreamRemoteAddress).

Validator:
* Restore the rejection of nil clientIPDetection in
  validateAuthorizationGeoIP. The new mode requires an explicit non-nil
  ClientIPDetection with DownstreamRemoteAddress set.

Translator:
* Add an explicit switch arm in buildHCMGeoIPFilter that emits the geoip
  filter with neither xff_config nor custom_header_config when
  DownstreamRemoteAddress is set, so Envoy uses its documented default
  (the immediate downstream connection source address). HCM-side wiring
  needs no change: useRemoteAddress remains true since no
  original_ip_detection_extensions are produced.

Tests:
* Restore the gatewayapi golden testdata for the rejection case
  (byte-identical to upstream/main).
* Add positive gatewayapi + xDS golden coverage for the new mode.
* Update CEL validation tests for the new mutual-exclusion message and
  add positive/negative cases for downstreamRemoteAddress.

Docs and release notes updated to describe the explicit field.

Signed-off-by: Salim Boulkour <[email protected]>

…moteAddress field

These golden files render the ClientTrafficPolicy CRD inside the helm chart and need to reflect the new downstreamRemoteAddress field plus the updated CEL mutual-exclusion message. Caught by 'make gen-check'.

Signed-off-by: Salim Boulkour <[email protected]>

Tighten ClientTrafficPolicy.clientIPDetection validation from "at most
one" to "exactly one" of {xForwardedFor, customHeader,
downstreamRemoteAddress}. This rejects an empty object (`{}`) and
aligns behavior with the explicit opt-in requirement for GeoIP source
selection.

Also add a defensive runtime validation in authorization GeoIP
translation so stale resources (or bypassed admission validation) are
rejected unless exactly one mode is configured.

Tests updated:
* gatewayapi unit tests: reject empty and multi-mode clientIPDetection.
* CEL validation tests: updated error message and added empty-object
  rejection case.
* regenerated CRD/docs/helm golden outputs for the new CEL rule and
  message.

Signed-off-by: Salim Boulkour <[email protected]>

Per reviewer feedback, DownstreamRemoteAddress is too Envoy-internal.
DirectRemoteAddress better describes the user-facing intent: use the
direct TCP peer address as the client IP.

Also add breaking change release note entry for the strict one-of
CEL validation on clientIPDetection.

Signed-off-by: Salim Boulkour <[email protected]>

Signed-off-by: Salim Boulkour <[email protected]>

…dress

Signed-off-by: Salim Boulkour <[email protected]>

The sed-based rename accidentally changed downstreamRemoteAddressWithoutPortCelFormatter
in ratelimit.go, which is a rate-limiting internal constant unrelated to
the directRemoteAddress GeoIP feature. Revert to original name.

Signed-off-by: Salim Boulkour <[email protected]>

Replace the removed monolithic release-notes/current.yaml edits with
per-section fragment files introduced by envoyproxy#9312:
* breaking_changes/8956: clientIPDetection now requires exactly one mode.
* new_features/8956: add directRemoteAddress for L4-transparent geoip.

Signed-off-by: Salim Boulkour <[email protected]>

Per maintainer consensus on envoyproxy#8956 (zhaohuabing, jukie, apkatsikas),
rename the new client-IP detection mode from directRemoteAddress to
directSourceIP. directSourceIP reads more intuitively as "the source IP
of the direct connection terminated by Envoy" while avoiding the
Envoy-internal 'remote address' phrasing.

* API: rename field DirectRemoteAddress -> DirectSourceIP, type
  DirectRemoteAddressSettings -> DirectSourceIPSettings, JSON tag
  directRemoteAddress -> directSourceIP, and the CEL one-of message.
* Validator/translator: update field references and error string.
* Tests: gatewayapi unit, CEL validation, and renamed testdata
  fixtures/goldens (gatewayapi + xDS).
* Docs and release-note fragments updated; regenerated CRDs, helm
  goldens, deepcopy, and extension_types.md.

Signed-off-by: Salim Boulkour <[email protected]>

…ource

The clientIPGeoLocations doc comment still listed only X-Forwarded-For and a custom header as client-IP sources, omitting the directSourceIP mode added in this PR. Update the comment and regenerate the API reference doc accordingly. Addresses review feedback from zhaohuabing.

Signed-off-by: Salim Boulkour <[email protected]>

… comment

The clientIPGeoLocations Go doc comment update also lives in the generated SecurityPolicy CRD manifests and helm test goldens. Regenerate them via 'make manifests helm-template' so gen-check passes.

Signed-off-by: Salim Boulkour <[email protected]>