[Meta] Implement context propagation for Kibana entities

[mshustov]

Use the service introduced in #102626 to instrument Kibana code with runtime context metadata:
Phase I:

• Visualizations
  • vis_type_metric
  • vis_type_table
  • vis_type_tagcloud
  • vis_type_timelion
  • vis_type_timeseries
  • vis_type_vega
  • vis_type_vislib
  • vis_type_xy
  • vis_type_pie
  • input_controls_vis
• Lens
• Discover
• Dashboards
• Kibana server request handlers
• Tasks
  • Actions
  • Alerts

Phase II (TBD dates)

• Implement a generic solution to execution context propagation inside Kibana #132629 (replaces all issues bellow
• Propagate execution context from Maps
• Propagate execution context from Dev Tools
• Propagate excution context from Management #126802
• Propagate execution context from Canvas #126797
• Propagate execution context from Observability #126798
• Propagate execution context from Security solutions #126799
• [ML] Propagate execution context from ML #126800
• Propagate execution context from Enterprise Search #126801
• Tasks
  • Reporting

Acceptance Criteria

1. Execution context propagates from a Kibana frontend application to the Core service of the Kibana server (if applicable).
2. Execution context propagates from a Kibana backend application to the Core service of the Kibana server (if applicable).
3. The integration has an appropriate integration test.

Nested context

#102626 will add the ability to create nested / linked contexts. It can be used to compose execution context relationships across different apps.
Application service context --> Dashboard context --> Visualization context.

Integration with embeddable

As discussed with @ppisljar we need to extend EmbeddableInput interface with executionContext

kibana/src/plugins/embeddable/common/types.ts

Line 16 in 859caf2

export type EmbeddableInput = {

In the turn, every application creating an embeddable container will create application-specific execution context object and provide it as a part of input when calling updateInput

kibana/src/plugins/embeddable/public/lib/embeddables/embeddable.tsx

Line 152 in 859caf2

public updateInput(changes: Partial<TEmbeddableInput>): void {

How to test

automatic testing

It's better to automate the check to prevent unexpected failures in the future. You can use these files as a referenced implementation of the functional tests.
for the client side code
for the server side code

manual testing

Steps to test the PR manually:

• setup logging to observe request.id: opaqueId in elasticsearch response and execution_context whenever it's set

logging:
  appenders:
    myconsole:
      type: console
      layout:
        type: pattern
        pattern: '%date|%meta'
  loggers:
    - name: elasticsearch.query
      level: all
      appenders: [myconsole]
    - name: execution_context
      level: debug
      appenders: [console]

• run Kibana
• navigate to your app
• simulate user interactions that lead to ES requests
• You should be able to see the log output like this:

[2021-07-12T13:14:28.944+03:00][DEBUG][execution_context] stored the execution context: {"requestId":"d568e29f-c3de-4ef6-a311-225b1358f8b7","type":"visuzalization","name":"gauge","description":"[eCommerce] Average Sales Price","id":"4b3ec120-b892-11e8-a6d9-e546fe2bba5f","url":"/bon/app/visualize#/edit/4b3ec120-b892-11e8-a6d9-e546fe2bba5f"}

2021-07-12T13:14:28.965+03:00|{"http":{"request":{"id":"d568e29f-c3de-4ef6-a311-225b1358f8b7;kibana:visuzalization:gauge:4b3ec120-b892-11e8-a6d9-e546fe2bba5f"}}}

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[lizozom]

I think that the merge of #124996 changes the second phase of this issue.
Instead of propagating the context manually, solutions should make sure to call useExecutionContext on their pages, similar to what we did for discover, visualize, dashboard, maps and dev_tools on that PR.

I think we could create issues for solutions to start working on it at their own pace. What do you think?

[mshustov]

Instead of propagating the context manually, solutions should make sure to call

I wouldn't say these things are mutually exclusive, but rather they complement each other. We can ask Solution teams to instrument their code with useExecutionContext as Phase II, but why not propagate context manually at the same time if possible? We can postpone manual propagation until Phase III for cases requiring significant effort.

[xcrzx]

@lizozom @mshustov I have created an issue on implementing a generic solution to execution context propagation: #132629. Which I have already partially implemented in this PR. So I think tasks in this epic from the phase II are not needed anymore and can be closed.

[lizozom]

@xcrzx thank you!
I've crossed the remaining items out.
Is #132629 something you're considering to take on?

[xcrzx]

Is #132629 something you're considering to take on?

Yea, I think so. Just need to align with my team before taking that task. I'll come back to you with an update, likely at the beginning of next week.

[lukeelmers]

@lizozom Just to confirm, we skipped manually implementing context propagation in Canvas, Observability, Enterprise Search, and Reporting, in favor of #132629 -- correct? I assume those apps will need to switch to using the shared router then