Support sharing Wasm VMs across EnvoyExtensionPolicies for identical filters

Description:

I would like Envoy Gateway to support configuring the Envoy Wasm vm_id for Wasm extensions defined in EnvoyExtensionPolicy, so identical Wasm filters configured across multiple policies can intentionally share the same Envoy Wasm VM.

Problem

We use multiple EnvoyExtensionPolicy resources to control which services/routes receive a given Wasm filter. In some cases, those policies configure the exact same Wasm filter logic, for example an auth-filter-a Wasm extension attached at a per-service level.

Today, each EnvoyExtensionPolicy results in a distinct generated Wasm filter/VM identity. Even when the Wasm filter configuration is logically identical across policies, Envoy Gateway generates unique VM IDs, so Envoy starts separate Wasm VMs instead of reusing one.

That preserves isolation by default, which is a good default, but there is currently no way for users to opt in to sharing a VM for the same filter across policy resources.

Use case

I want to configure the same Wasm filter across multiple EnvoyExtensionPolicy resources and have Envoy use the same Wasm VM when the filter is intentionally identical.

For example:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
  name: service-a-auth
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: service-a
  wasm:
  - name: auth-filter-a
    vmID: shared-auth-filter-a
    code:
      type: HTTP
      http:
        url: https://example.com/auth-filter-a.wasm
        sha256: <sha256>
---
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyExtensionPolicy
metadata:
  name: service-b-auth
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: service-b
  wasm:
  - name: auth-filter-a
    vmID: shared-auth-filter-a
    code:
      type: HTTP
      http:
        url: https://example.com/auth-filter-a.wasm
        sha256: <sha256>

In this example, both policies intentionally configure the same filter, auth-filter-a, with the same Wasm module. The desired behavior is for Envoy Gateway to pass shared-auth-filter-a through to Envoy's VmConfig.vm_id, allowing Envoy to reuse the same VM for both filters.

Proposed behavior

Add an optional vmID field to the Wasm API type in EnvoyExtensionPolicy.

Suggested semantics:

• If vmID is omitted, preserve the current behavior: Envoy Gateway uses its generated per-policy/per-filter identity as the VM ID, keeping isolation by default.
• If vmID is set, Envoy Gateway passes that value through to xDS extensions.wasm.v3.VmConfig.vm_id.
• Filters with the same vmID and same Wasm code can then share a VM according to Envoy's existing Wasm behavior.
• The field should be optional and non-empty when present.
• The existing name field should continue to identify the Wasm plugin/filter for logging/debugging, while vmID controls VM reuse.

Why this matters

For deployments that attach the same Wasm filter through multiple EnvoyExtensionPolicy resources, the current behavior can create duplicate Wasm VMs for identical filter logic. A user-controlled vmID would let operators intentionally reuse a VM where appropriate, while keeping Envoy Gateway's current isolated default for everyone else.

This is particularly useful when policies are managed per service or per route, but the underlying Wasm filter is the same.

Compatibility

This should be backward compatible because vmID would be optional. Existing policies that omit vmID would continue to get the current generated VM ID behavior and remain isolated.

Alternatives considered

• Reusing the existing name field as the VM ID: this seems undesirable because Envoy's Wasm plugin name and VM vm_id have different meanings.
• Deriving a stable VM ID automatically from the Wasm code/configuration: this could unexpectedly change isolation behavior for existing users.
• Keeping the current behavior only: users cannot opt in to Envoy's native VM sharing behavior across policies.

[optional Relevant Links:]

• Envoy Wasm VmConfig.vm_id docs: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/wasm/v3/wasm.proto
• Current Envoy Gateway Wasm documentation: https://gateway.envoyproxy.io/latest/tasks/extensibility/wasm/