[skip-ci] [POC] Use x-opaque-id to associate search request with user/saved object

[lukasolson]

Summary

Associates a request with a given user/saved object using the X-Opaque-Id. This will be useful for admins to troubleshoot where requests are coming from using the Elasticsearch task management APIs.

Addresses #16493.

Currently the format of the header isusername:saved_object_type:saved_object_id, but this is open to discussion:

This is only a proof of concept, and currently only works in Discover, and you have to add the following in your kibana.yml:

elasticsearch.requestHeadersWhitelist: ["authorization", "X-Opaque-Id"]

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-app-arch

[kobelb]

Whenever I've thought about adding something along these lines before, I've generally thought about it from the perspective of wanting to trace a single HTTP request to a Kibana API to the resultant calls to Elasticsearch, though I see merit in both approaches.

Once everything is switched to the NP, it's theoretically possible to use the request interceptors to add a header to every request that includes the URL (including the hash) that initiated the XHR. If we weren't using hash based routing this would already be available in the Referer request header.

(Apologies for the unsolicited feedback)