Make expression renderer aware of current context

[flash1293]

When rendering the result of an expression in an expression renderer, it is sometimes important to have some information about the context the result is rendered in because it can influence different aspects. In the case of Lens, there are several real world use cases for this:

• noInteractivity: When a Lens visualization is embedded in a Canvas workpad, filter actions can't be dispatched. But the chart renderer doesn't know about this and is still appearing interactive (e.g. changing the cursor when hovering over bars and letting the user brush to select a range on the x axis which doesn't have any effect). [Lens] Option to disable interactions #65630
• edit: In Lens there a features planned that would require to offer some chart interactivity only when within the Lens editor, not on dashboards. [Lens] Client side table sorting #76962
• preview: Lens is rendering visualizations in a "preview" mode in suggestions. This is currently done using a special separate expression, but could be solved more easily using a mode passed directly to the renderer

Proposal

This can be done by adding a mode option to the expression runner / component wrapper as part of the IExpressionLoaderParams:

<ExpressionRenderer expression={expression} mode="edit" />

This mode which is restricted by an enum ('noInteractivity' | 'edit' | 'preview' | 'display' with defaulting to 'display') is exposed to the renderer as part of the handlers:

{
  name: 'my_renderer',
  render: async (
    domNode: Element,
    config: MyProps,
    handlers: IInterpreterRenderHandlers
  ) => {
    if (handlers.getMode() === 'edit') { /* ... */ }
  }
}

As the possible modes are defined in a central place, this becomes a part of the generic contract of expression renderers. When implementing a renderer, it should respect the current mode as well as it can.

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[elasticmachine]

Pinging @elastic/kibana-app-arch (Team:AppArch)

[timroes]

I like that idea a lot. I wonder if we should still add a print or reporting value, that we could potentially leverage with some changes later in the reporting infrastructure. Usually this will most likely be similar to noInteractivity, but perhaps some charts could make reasonable distinction when drawing in report mode, e.g. one random example coming to my mind: input controls would most likely be disabled in noInteractivty mode, but could e.g. not draw at all like inputs, but in a more "overview which filters are applied" way in report mode.

[flash1293]

No strong opinion on the actual modes yet. I wonder whether we should have a map of settings instead of a single-dimension "mode".

[flash1293]

@ppisljar FYI, I'm starting to work on this.