feat(api): merge backends

[muwaqar]

What type of PR is this?

What this PR does / why we need it:

this is an initial scaffolding of api changes to support #5307
it introduces a new MergeBackends flag, when the flag is enabled:

• xRoutes without BackendTrafficPolicy attached to them will be de-duplicated
• xRoutes with BackendTrafficPolicy where ClusterSettings fields are not populated will be de-duplicated
• xRoutes with BackendTrafficPolicy where ClusterSettings fields are populated will continue to behave as currently (per-HTTPRouteRule CDS entry)

also introduced is BackendPolicy which can be attached to a backend directly and customizes that backend behavior.

some open questions I have are:

• ClusterSettings currently contains Retry but this is a RDS-level setting, not CDS. thought of moving Retry out into the parent struct, but it is a backwards incompatible change to BackendCluster struct (used by ExtAuthz, ExtProc, JWT, OIDC etc.)
• Unsure if MergeBackends belongs in EnvoyProxy or EnvoyGateway config.

Which issue(s) this PR fixes:

Fixes #5307 (api scaffolding only)

Release Notes: Yes/No

[zirain]

this sounds like a good solution for #7520

[arkodg]

hey @muwaqar can we start off with a design doc for this, it doesnt need to be very formal, that can live in https://gateway.envoyproxy.io/contributions/design/

another idea id like to throw here if a user opts into a field setting like MergeBackends , EG could automatically dedup (backend, xBTP) tuples

[guydc]

+1 to the merge backends option

[muwaqar]

can we start off with a design doc for this

I agree that this is a fundamental change to current behavior to EG and quite an involved implementation change, so better to chart this out in a design doc so that the end state is clear. I shall start one, hoping to target the design closure by 1.7, the implementation would likely go into future milestones.