docs: add proposal for MADS v1 API

[austince]

Summary

Coming from this slack conversation, this proposes a v1 API for the MADS observability protocol for exposing externally (i.e. to Prometheus) for service discovery of metrics targets. Please let me know if I've gotten things wrong about the current implementation!

kuma-cp --> MADS v1 HTTP server <--xDS v3--> Prometheus kuma_sd (polling)

This will also support serving multiple versions of the MADs API, so we can provide an easy migration path.

Full changelog

• Add MADS v1 proposal

Related Issues

• Provide even more native integration with Prometheus #961
• Proposal: Add Kuma service mesh SD mechanism prometheus/prometheus#7919
• Metrics semantic convention: "up" metric open-telemetry/opentelemetry-specification#1078 (comment)

Follow Ups

• We will need to implement the HTTP-variant of the final API
• We will need to add a client and discovery implementation in Prometheus

[austince]

I started a WIP implementation in the feat/mads/v1 branch (API) (MADS) (Prometheus SD), where I've found that more explicit fields will be easier to implement in the SD on the Prometheus side. Much more refactoring needs to be done on that branch, lot of duplication currently. We'll also need to implement the HTTP server, but the base server in envoyproxy/go-control-plane looks like it will make it not too hard.

I've also implemented the Kuma SD with an xDS HTTP client in my Prometheus fork here.

[austince]

Closing in favor of: #1753