Service Mesh WASM module use-case (ORIGINAL_DST socketopt and TLS support)

Hello! I'm an Istio maintainer intrigued at the possibility of a service mesh WASM module, and @pchickey pointed me to this repo so I could see the status of WASI preview 2. I came across WebAssembly/wasi-sockets#9 and read through the discussion, and I see that the getter/setter approach for specific sockopts was adopted in the spec. While I don't have the context to comment on that decision, I did want to provide the community with some more information on our use-cases from the service mesh side that will hopefully shed some light on the request.

In general, service meshes provide transparent proxy functionality, meaning that the application binary doesn't need to change anything about how it calls services to be onboarded to the mesh. A big part of how that "magic" works in a Kubernetes environment is via the SO_ORIGINAL_DST socket option that allows a proxy to retrieve the the original destination address on the socket after the ClusterIP Service does its load balancing.

Also absent from the current version of the spec is any kind of TLS support (probably for good reason!) which would be crucial for any kind of mesh module implementation. I'm aware of a few efforts to compile crypto modules to WASI, but the *.wit interfaces for handling/verifying certificates would need to be in the spec for a mesh to be feasible.

This is by no means a demand to modify the spec immediately; I simply wanted to provide context for what I believe to be a really interesting WASI use case, and I'd be happy to work with the community to try and make it happen at some point 😄

Start with the service-mesh use cases in this issue and the linked wasi-sockets#9 discussion, then review the current WASI Preview 2 socket interfaces. There are no files or tests named; completion would require an agreed scope for ORIGINAL_DST socket options and TLS or certificate support in the relevant WASI specification.