cookie vs cookies

_**TL;DR:** If an agent records the headers of an incoming HTTP request, it shouldn't leave out the `cookie` header just because it also sends up the parsed cookies as a separate object under `context.request.cookies`._

According to our API, when capturing the cookies on the transaction for an incoming request, it's possible to store them in two different places in our API:

- `context.request.headers.cookie` (unparsed, string)
- `context.request.cookies` (parsed, key-value pairs)

For better searching, the parsed version is most convenient. And in some languages, we don't even have access to the raw headers, and therefore not the unparsed string version. But for the user it's my experience that it does provide a lot of value to be able to see the "raw" headers of a request. So if possible I think we should always send both.

But there's a few of our agents that send up all the regular headers except the `cookie` header - and instead send the `cookies` object. I think this can lead to a lot of confusion for users. If you as a user is just looking at the headers object, it's potentially very confusing to see all headers except one. There's no warning in the UI that one of the headers was removed. This can lead the user to debug why they are not sending up that header when in fact they are.

Therefore I think it's important that - if we send up all other headers - we also make sure to send the `cookie` header.

@elastic/apm-agent-devs What do you think about this proposal? Any blockers for this that I haven't thought about?