wasm: add support for OCI registries

[jewertow]

Related to: #33212

This is a prototype implementation of fetching WASM plugins from OCI registries. I want to know if the implementation goes in the right direction, share my findings and challenges I faced and hear your opinion on whether it's worth developing it further.

Image format:
I assumed we will support the following image format, as it is widely adopted by registries.

{
  "schemaVersion": 2,
  "config": {
    "mediaType": "application/vnd.wasm.config.v1+json",
    "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
    "size": 2
  },
  "layers": [
    {
      "mediaType": "application/vnd.wasm.content.layer.v1+wasm",
      "digest": "sha256:4c7915b4c1f9b0c13f962998e4199ceb00db39a4a7fa4554f40ae0bed83d9510",
      "size": 1624962
    }
  ]
}

Fetching proces:
According to the OCI spec, we have to perform 2 subsequent requests: GET /v2/<repo>/manifests/<tag> and GET /v2/<repo>/blobs/<digest>. This is done by OciImageManifestsFetcher and OciImageBlobFetcher.

Authentication and authorization:
This is not covered by the OCI distribution spec, but different registries support different authentication methods. I tested ECR and Docker Hub, and they work as follows:

1. ECR uses basic auth and requires authorization header in the endpoints for manifests and blobs, but not in the temporary location when /blobs returns 307 (then in returns X-Amz-Security-Token in the URL).
2. Docker requires bearer token to get manifests and blobs, and that token can be obtained from auth.docker.io using basic authentication.
3. I did not test ACR and GCR.

Redirects:
This is also not described in the OCI distribution spec, but both ECR and Docker returns 307 with temporary location to requests for /blobs.

Dynamic cluster resolution:
Because of redirect responses with locations, which we can't predict, we will probably need envoy.extensions.clusters.dynamic_forward_proxy.v3.ClusterConfig, but it does not work if the hostname is not resolved by the filter, so createWasm would have to resolve DNS names...

API changes
I wanted to reuse as much as we already have, so I did not add oci_uri to the API. Instead, I'm checking if the URI starts with oci://. Additionally, I added basic_credentials to send basic auth header.

Reading a secret:
Reading a secret during plugin creation can't be done if the secret is for outbound traffic, because in such a case the filter is created with the factory method that takes Envoy::Server::Configuration::ServerFactoryContext, which does not provide TransportSocketFactoryContext required to read the secret. Making this work would require to change many other filter factories in the code base.

[repokitteh-read-only]

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #37635 was opened by jewertow.

see: more, trace.

[repokitteh-read-only]

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @abeyad
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

🐱

Caused by: #37635 was opened by jewertow.

see: more, trace.

[jewertow]

@kyessenov @zhaohuabing @arkodg @mathetake WDYT?

[arkodg]

from the envoy calendar, looks like kuat is away until March, cc @mpwarres