Using point in time API instead of client side time conversion

[Dosant]

part of #80406

Kibana converts relative time range to absolute on a client and search executed with absolute time range.
This is used for multiple things:

• Sync time on a dashboard between different panels
• Generating reports using forceNow query param to set original client's time now [Reporting] remove forceNow hack #110568
• Caching in vega and + soon lens
• Restoring search sessions

Currently not all places that communicate with the server convert to absolute time range.
For example,

• aggs/buckets/date_range.ts is using relative time ranges.
• We do not convert input in query and filter
• Conversion isn't centralized, so not really reliable, there are probably other places we don't know about.

This now will likely soon come up in server-side expression.

Instead of addressing all places where we don't do the conversion, we could explore using point in time API: https://www.elastic.co/guide/en/elasticsearch/reference/master/point-in-time-api.html instead

cc @ppisljar

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[tsullivan]

Generating reports using forceNow query param to set original client's time

cc @elastic/kibana-reporting-services

[lukasolson]

Following up on our discussion this morning, I'm not sure PIT will solve this particular use case. For example, follow these steps:

1. Index a couple of documents into an index (one before now & one a few minutes from now):

POST /my-index-000001/_doc
{
  "@timestamp": "2021-09-20T22:58:28.820Z
}

POST /my-index-000001/_doc
{
  "@timestamp": "2021-09-20T23:01:28.820Z"
}

Then, create a PIT:

POST /my-index-000001/_pit?keep_alive=10m

Search the PIT using a filter of < now:

POST /_search
{
  "query": {
    "range": {
      "@timestamp": {
        "lt": "now"
      }
    }
  },
  "pit": {
    "id": "your_pid_id"
  }
}

Notice that only one document shows up. Wait until the timestamp of the second document is before "now", then search the PIT again, and you'll see that both documents show up. This shows that now is not relative to when the PIT itself was created.

[elasticmachine]

Pinging @elastic/kibana-data-discovery (Team:DataDiscovery)