Add destination spec

[felixbarny]

The goal of this PR is to document the status quo. So it mainly converts #180 into a proper spec. Additionally, describes the ES mapping, what the fields are used for, and discusses considerations around cardinality.

I think there's potential to simplify destination handling, which is especially needed when we want to open it up to users to set the destination in #424.
We may brainstorm some of the potential simplifications in this PR but I want to strictly separate documenting the status quo from any enhancements.

For example, as destination.service.name and destination.service.type are not used, and as there are no immediate plans (AFAIK) to use them, we might want to consider dropping them in the future.
Another thing to think about is whether we can auto-fill the destination fields based on other properties.
See also #424 (comment)

[apmmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Build Cause: Started by timer

• Start Time: 2021-04-26T04:57:00.770+0000

• Duration: 3 min 55 sec

• Commit: f5e5a20

Trends 🧪

[AlexanderWert]

Can we somehow cover the following scenario within this SPEC, that would us allow for corresponding visualization in the UI in the future:

What if a resource provides different ways of accessing it? For instance Azure's CosmosDB allows usage through an SQL API, MongoDB API, Cassandra API, Table API, etc. Similar with AWS' DocumentDB, and there are for sure more examples.

In this case the resource is the actual cloud service (e.g. CosmosDB) but the service type is the access layer (e.g. MongoDB API).

[felixbarny]

I'd see that as an enhancement of the spec and would like to not include it in the first version. Also, does the client even know it's not talking to MongoDB but a MongoDB API-compatible service? To which length would we want to go (such as making a query for a metadata table) in order to detect that?

[felixbarny]

Merging now as it just documents the status quo and we have a good number of approvals already. Feel free to either comment on this PR or create a follow-up PR if there's more to discuss.