Commit Message: wasm: add initial support for OCI registries
Additional Description: This is an initial implementation of OCI client for fetching images.
Risk Level: medium
Testing: TODO
Docs Changes: Documentation will be added when the feature will be complete.
Release Notes: TODO
Fixes: #33212
Runtime guard: envoy.reloadable_features.wasm_plugin_enable_fetching_from_oci_regisitry (disabled by default).

Implementation details

Image format:
Currently, it supports image format compatible with WASM Artifact Image Specification v0.0.0. Other formats, like compat, can be added in next iterations.

{
  "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, Envoy has to send 2 subsequent requests: GET /v2/<repo>/manifests/<tag> and GET /v2/<repo>/blobs/<digest> to fetch an image. However, registries may return 307 and redirect blob request to custom location, e.g. S3. So eventually Envoy must send at least 3 requests.

Dependency on DFP cluster:
Handling redirects requires dynamic cluster resolution, so the only practical solution is using dynamic forward proxy cluster.

Authorization:
Different registries support different authorization strategies. ECR, ACR and GCR use basic scheme and require the credential from the image pull secret. Docker on the other hand uses bearer scheme and requires additional authorization request to obtain a token.

API changes
I wanted to avoid significant API changes, so currently Envoy uses httpUri and checks if it starts with oci://, to decide if it should use RemoteDataFetcher or OCI fetcher. Additionally, I added image_pull_secret field that specifies the secret from which Envoy reads credential. Currently, this field is hidden from the documentation.

Here you can see example working configuration.

Implementation status

In this iteration, I was focused on introducing scaffolding for the OCI client that has minimal impact on the existing code base, and reuses existing code for fetching from HTTP URI. I wasn't able to test it with GCR and ACR yet, so it works only with ECR for now.

I would like to address missing features in follow-up PRs. I suggest adding support for missing features as follows:

1. ACR and GCR - this will require testing and making sure that those don't need additional authorization for getting blobs.
2. Docker - implement callback for bearer authorization.
3. Compat format.
4. Quay (requires compat).
5. Enable other registries - at this point we should have all required building blocks, i.e. authorization callback and appending authz header if not included in temporary location path.

If the direction of this PR is acceptable, I will add missing unit tests.