[Doc] Runtime fields and Grok - additional example and Grok pickiness

[toby-sutor]

At https://www.elastic.co/guide/en/elasticsearch/reference/master/runtime-examples.html#runtime-examples-grok we are documenting how to use runtime fields in the mapping. Can we please also elaborate that this can be used in a search query. E.g.:

GET my-index/_search
{
  "runtime_mappings": {
    "clientip": {
      "type": "keyword",
      "script": {
        "source": """
        String clientip=grok('%{COMMONAPACHELOG}').extract(doc["message"]).value)?.clientip;
if (clientip != null) emit(clientip);
"""
      }
    }
}
}

In addition would it be worth to document that accessing tokenized values (neither keyword nor wildcard but text with fielddata) via .extract(params["_source"]["message"]) (instead of .extract(doc["message"])).

Finally, Grok seems to be more picky on the runtime fields compared to the Kibana Grok debugger - especially on the whitespaces. E.g.
Raw: "clientip = 127.0.0.1"
Kibana Grok debugger: clientip = %{COMMONAPACHELOG} - will match
Runtime Grok: grok("clientip = %{COMMONAPACHELOG}") - will not match and requires grok("clientip\\s=\\s%{COMMONAPACHELOG}") instead.

Ref. https://github.com/elastic/sdh-elasticsearch/issues/4361

[elasticmachine]

Pinging @elastic/es-docs (Team:Docs)

[elasticmachine]

Pinging @elastic/es-search (Team:Search)

[lockewritesdocs]

I just tested @cbuescher's findings and did not have to mask spaces in the grok pattern. For example String ap=grok('apname = %{NOTSPACE:ap}').extract(doc["message"].value)?.ap; works without having to mask the spaces on either side of the =. The successful search request example looks like this:

GET my-index-000001/_search
{
  "runtime_mappings": {
    "router_name": {
      "type": "keyword",
      "script": {
        "source": """
        String ap=grok('apname = %{NOTSPACE:ap}').extract(doc["message"].value)?.ap;
if (ap == null) emit("value not found!");
if (ap != null) emit(ap);
"""
      }
    }
  },
  "size": 3,
  "fields": [
    "router_name"
  ]
}

[lockewritesdocs]

I think that we can handle updates for this issue via #73118, which adds a new page specifically for grok in the scripting docs.