* Shrink and better document the debug image

before: 722MB
after: 236MB
(Not counting envoy itself)

Fixes envoyproxy#423

Needs istio/old_pilot_repo#1202 to fully work

```release-note
Reduce proxy debug image by 2/3rd (486Mb) yet as functional
```

* Alignement fix

Automatic merge from submit-queue.

Add LRU cache for service config.

**What this PR does / why we need it**:

To support dynamic service config change.
service config is coming from Envoy per-route in RDS.  It can be changed overtime without re-contructing mixer fitter or mixer client control object.   
Add a LRU cache to store these known service config.

**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #

**Special notes for your reviewer**:

**Release note**:

```release-note
None
```

Signed-off-by: Piotr Sikora <piotrsikora@google.com>

envoyproxy#423)

* zh-transsaltion: docs/root/configuration/listeners/network_filters/direct_response_filter.rst

* fix translate

* add ,

Right now, if a consumer fails to set any closure in the `EnvoyHTTPCallbacks`, a crash will occur when the `EnvoyHTTPStreamImpl` attempts to call the closure.

It's reasonable to assume that a consumer might not care about each available callback (i.e., never setting `onCanceled`). We can guard against this by validating each closure is actually set before trying to call it.

Tested locally and this solves the problem.

Signed-off-by: Michael Rebello <me@michaelrebello.com>
Signed-off-by: JP Simard <jp@jpsim.com>

Right now, if a consumer fails to set any closure in the `EnvoyHTTPCallbacks`, a crash will occur when the `EnvoyHTTPStreamImpl` attempts to call the closure.

It's reasonable to assume that a consumer might not care about each available callback (i.e., never setting `onCanceled`). We can guard against this by validating each closure is actually set before trying to call it.

Tested locally and this solves the problem.

Signed-off-by: Michael Rebello <me@michaelrebello.com>
Signed-off-by: JP Simard <jp@jpsim.com>

**Commit Message**

This adds a proposal doc on the support for Gateway API Inference
Extension in Envoy AI Gateway project. This involves the change of the
project scope as well as we need to make sure that the existing API
layer will co-exist nicely with the GAIE.


**Related Issues/PRs (if applicable)**

Preliminary to #423

---------

Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>
Signed-off-by: Erica Hughberg <erica.sundberg.90@gmail.com>
Co-authored-by: Erica Hughberg <erica.sundberg.90@gmail.com>

**Commit Message**

This commit scaffolds the foundation for the Inference Extension API
[1]. The design documentation was merged in #492. The controller needs
to be started with `--enableInferenceExtension=true` to not break the
existing controller deployment where the Inference Extension CRDs are
not installed.

This commit doesn't implement the actual "metrics-aware" load balancing
and instead it just does the random routing out of given (resolved)
endpoints. The follow up implementations will add more advanced
algorithm while expanding the metrics interface that currently only
provides the setter APIs.

The summary of the implementation is:
* Added `kind` field to AIGatewayRouteRuleBackendRef so that it can
reference InferencePool.
* InferencePool.Spec.Selector is allowed to specify multiple
AIServiceBackend.
* When building up all the extproc config via filterapi.Config, the
controller reads the referenced InferencePool and its binding
InferenceModels, and group them together into a single
filterapi.DynamicLoadBalancing configuration.
* When the extproc loads the configuration containing
DynamicLoadBalancing, it will resolve all the IP addresses for hostnames
belonging to the DyanmicLoadbalancing. The presence of
DynamicLoadBalancing in th config forces the config watcher reload and
refresh the config regardless of the updates. That way, the list of ip
addresses will always be updated (eventual consistency anyways) in a
non-hot path.
* On the request path, the ChatCompletionProcessor will check the
existence of the DynamicLoadBalancing config for the backend selected by
the router. If so, it further tries to resolve the ip:port level
endpoint selection.
* The selected ip:port will be set to the special header that will be
routed to ORIGINAL_DST.
* ORIGINAL_DST cluster will be added by the EG extension sever
implementation. Also, the extension server modifies some routes to
properly route to that cluster.

1: https://github.com/kubernetes-sigs/gateway-api-inference-extension

**Related Issues/PRs (if applicable)**

Built on #492
Contributes to #423

---------

Signed-off-by: Takeshi Yoneda <t.y.mathetake@gmail.com>

**Description**

Article for the blog sharing how one can use Envoy AI Gateway in context
together with KServe.
Also, organizing the blog directory for easier management of blog files.

**Related Issues/PRs (if applicable)**

n/a

**Special notes for reviewers (if applicable)**
Article written by myself and @alexagriffith
This article mentions the pending work of #423, which @Xunzhuo is
working on for the KServe integration, and includes a note referencing
this. When the work is done, we can go back and update the article. :)

---------

Signed-off-by: Erica Hughberg <erica.sundberg.90@gmail.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

**Description**

Update blog as envoyproxy/ai-gateway#423 is
closed

**Related Issues/PRs (if applicable)**
Related Issue: #423 


**Special notes for reviewers (if applicable)**

n/a

Signed-off-by: Erica Hughberg <erica.sundberg.90@gmail.com>
Co-authored-by: Takeshi Yoneda <t.y.mathetake@gmail.com>