[Lens] Register all expression functions to the server

[flash1293]

To make it possible to run Lens expressions on the Kibana server (for features like alerting), all expression functions have to be registered on the server as well as on the client. To do that, they have to be moved to a central common folder in the plugin folder, and imported and registered in the server side plugin as well as the current registration on the client side.

List of functions:

• lens_time_scale
• lens_counter_rate
• lens_rename_columns
• lens_format_column
• lens_datatable_column
• lens_datatable (relies on field formatter service)
• lens_metric_chart
• lens_pie
• lens_xy_legendConfig
• lens_xy_yConfig
• lens_xy_tickLabelsConfig
• lens_xy_gridlinesConfig
• lens_xy_axisTitlesVisibilityConfig
• lens_xy_layer
• lens_xy_chart

We also have to move the suffix formatter to the server because the datatable function depends on field formatters x-pack/plugins/lens/public/indexpattern_datasource/suffix_formatter.ts

[elasticmachine]

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

[ghudgins]

there's a concern coming on this work in the future (not this issue): how does time zone get included as part of the execution context if we are moving things server side. for reporting we include time zone in the saved object. we can do this task (moving logic to server) as long as the client is initiating the request...but as soon as we take on async reporting or csv export we need a way to pass in the time zone in some way. need an issue for this

[wylieconlon]

@ghudgins The approach that reporting has taken for time zones is one that would also work for Lens, I believe this is already a solved problem. If a user doesn't pass the time zone to the reporting task, then it will fall back to the dateFormat:tz setting. If the dateFormat:tz setting is Browser, which is the default, then it will use the Kibana server timezone.

[flash1293]

@wylieconlon The "difficult" part here is that we would run an expression for these use cases (alerting/aggregated csv reporting) which is async for each function execution. So basically we would need to pass the current time zone to each expression function which would have to change the global moment timezone to the one of the current execution, then set it back to the server default (otherwise it can interfere with other runs). Maybe the interpreter can do this in a single place so we don't have to make sure each function is handling it.

Right now I think we would have an issue with time shifts and time scaling (both of them using moment, expecting it being set to the right time zone).

[dej611]

Meta issue: #71560

Some related issues:

• [Lens] Alerting from Lens Visualizations #71150
• [expressions] inspector alerting adapter #78277

[dej611]

Next steps:

1. Register the expression functions in common on server

• Mind getDatatable requires an async registration for the data formatter plugin
• Add the timezone info to expression context, when in browser pick it using moment, or fallback to UISettings when not provided
  • Make lens_time_scale function to pick it up from context

2. Extend render function to log data into the inspector

• Define dimensionName for each column on expression generation for each chart type
• Use adds dimensionName to datatable column meta information #106514 as reference implementation

[alexwizp]

the goal is achieved, the functions are available on the server, issue can be closed