Commit Message: this PR resolves the issue of incorrect handling of XFF trusted hops, which was inconsistent between the two approaches—OriginalIpDetectionExtension and HCM xffNumTrustedHops—used for retrieving the remote IP from the XFF header. Additionally, the old behavior in the OriginalIpDetectionExtension was also not aligned with the Envoy documentation, which specifies that the original IP should correspond to the rightmost trusted hop in the XFF header.

For example, for a requests going thourgh two trusted proxies, like this:

client(203.0.113.128) ----->proxy 1( 203.0.113.10) --------->proxy 2(203.0.113.1)--------> Enovy

proxy1 will add the client ip 92.168.1.1 to the XFF header, and proxy 2 will append it's direct upstream ip 92.168.1.2 to the XFF header. When Envoy finally receives the request, the xff header is X-Forwarded-For: 203.0.113.128, 203.0.113.10.

In this setup, the trusted hops is 2, and the correct client IP is the second rightmost ip in the XFF header 192.168.1.1

More details in the issue: #34241 (comment)

Additional Description:
Risk Level:
Testing:
Docs Changes: No
Release Notes: Yes
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #34241]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

Related Envoy Gateay issue: envoyproxy/gateway#4702

Request variables

Key	Value
ref	9620be6
sha	b957cf4
pr	37780
base-sha	66cc217
actor	@zhaohuabing
message	fix xff trusted hops...
started	1734754392.574805
target-branch	main
trusted	false

Container image/s (as used in this CI run)

Envoy version (as used in this CI run)